Each URL was manually verified to ensure it did not serve up incorrect
content.
Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df
Reviewed-on: https://go-review.googlesource.com/115798
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Change cgo to follow https://golang.org/s/generatedcode.
For the C code we continue to use /* */ comments, so they don't follow
the format exactly. It doesn't really matter since the format is only
for Go code anyhow. This CL changes the C code to be similar for
consistency.
Fixes#25623
Change-Id: Idcfee53ec4069924d173ab8cedeb7bcfb7312863
Reviewed-on: https://go-review.googlesource.com/115035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
We were using absolute paths in the #line directives in the export
header file. This makes the header file change if you move GOPATH.
The absolute paths aren't helpful for the final user, which is some C
program elsewhere.
Fixes#24945
Change-Id: I2da32c9b477df578bd5087435a03fe97abe462e3
Reviewed-on: https://go-review.googlesource.com/108315
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The export prologue goes into the _cgo_export.h file, where it may be
be #include'd by a .swig file. As SWIG defines its own type "intgo",
the definition of "intgo" in the export prologue could conflict.
Since we don't need to define "intgo" in the _cgo_export.h file, don't.
Defining "intgo" in _cgo_export.h was new for this release, so this
should not break any existing code.
No test case as I can't quite bring myself to write a test that
combines SWIG and cgo.
Change-Id: I8073e8300a1860cecd5994b9ad07dd35a4298c89
Reviewed-on: https://go-review.googlesource.com/83936
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Passing the absolute path to cgo puts the absolute path in the
generated file's //line directives, which then shows that path
in the compiler output, which the go command can then
make relative to the current directory, same as it does for
other compiler output.
Change-Id: Ia2064fea40078c46fd97e3a3b8c9fa1488f913e3
Reviewed-on: https://go-review.googlesource.com/77154
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cgo has always operated by rewriting the AST and invoking go/printer.
This CL converts it to use the AST to make decisions but then apply
its edits directly to the underlying source text. This approach worked
better in rsc.io/grind (used during the C to Go conversion) and also
more recently in cmd/cover. It guarantees that all comments and
line numbers are preserved exactly.
This eliminates a lot of special concern about comments and
problems with cgo not preserving meaningful comments.
Combined with the CL changing cmd/cover to use the same
approach, it means that the combination of applying cgo and
applying cover still guarantees all comments and line numbers
are preserved exactly.
This sets us up to fix some cgo vs cover bugs by swapping
the order in which they run during the go command.
This also sets up #16623 a bit: the edit list being
accumulated here is nearly exactly what you'd want
to pass to the compiler for that issue.
Change-Id: I7611815be22e7c5c0d4fc3fa11832c42b32c4eb3
Reviewed-on: https://go-review.googlesource.com/77153
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Permit the C preamble to use the _GoString_ type. Permit Go code to
pass string values directly to those C types. Add accessors for C
code to retrieve sizes and pointers.
Fixes#6907
Change-Id: I190c88319ec88a3ef0ddb99f342a843ba69fcaa3
Reviewed-on: https://go-review.googlesource.com/70890
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Fixes#21809
Change-Id: Ic43077c6bea3c7cdc9611e74abf07b6deab70433
Reviewed-on: https://go-review.googlesource.com/62670
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, cgo supports only macros which can be reduced to constants
or variables. The CL addresses remaining parts, macros which can be
represented as niladic functions.
The basic idea is simple:
1. make a thin wrapper function per macros.
2. replace macro expansions with function calls.
Fixes#10715Fixes#18720
Change-Id: I150b4fb48e9dc4cc34466ef6417c04ac93d4bc1a
Reviewed-on: https://go-review.googlesource.com/43970
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When calling a Go function that returns multiple values from C, cgo
generates a structure to hold the values. According to the documentation
this structure is called `struct <function-name>_return`. When compiling
for gccgo the generated structure name is `struct <function-name>_result`.
This change updates the output for gccgo to match the documentation and
output for gc.
Fixes#20910
Change-Id: Iaea8030a695a7aaf9d9f317447fc05615d8e4adc
Reviewed-on: https://go-review.googlesource.com/49350
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: I9d399db8ac26ad44adeace3bf1e5b11cbfe3e0d3
Reviewed-on: https://go-review.googlesource.com/41313
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change-Id: I0f8c695146b39cff72ca2374f861f3e9f72b0f77
Reviewed-on: https://go-review.googlesource.com/41314
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Current code doesn't support floating point #define macros.
This CL compiles floats to a object file and retrive values from it.
That approach is the same work as we've already done for integers.
Updates #18720
Change-Id: I88b7ab174d0f73bda975cf90c5aeb797961fe034
Reviewed-on: https://go-review.googlesource.com/35511
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The cgo tool used to simply ignore C type qualifiers. To avoid problems
when a C function expected a qualifier that was not present, cgo emitted
a cast to void* around all pointer arguments. Unfortunately, that broke
code that contains both a function declaration and a macro, when the
macro required the argument to have the right type. To fix this problem,
don't ignore qualifiers. They are easy enough to handle for the limited
set of cases that matter for cgo, in which we don't care about array or
function types.
Fixes#17537.
Change-Id: Ie2988d21db6ee016a3e99b07f53cfb0f1243a020
Reviewed-on: https://go-review.googlesource.com/33097
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
A bit contrived to come up with an example, but it happened in #15836, somehow.
$ cat /tmp/x.go
package main
/*
#include <stddef.h>
int foo(void);
int foo(void) {
return 2;
}
#define int asdf
*/
import "C"
func main() {
println(C.foo())
}
$ go run /tmp/x.go
# command-line-arguments
cgo-builtin-prolog:9:31: error: unknown type name 'asdf' <<<<<
_GoString_ GoStringN(char *p, int l);
^
/tmp/x.go:12:13: note: expanded from macro 'int'
#define int asdf
^
cgo-builtin-prolog:10:28: error: unknown type name 'asdf' <<<<<
_GoBytes_ GoBytes(void *p, int n);
^
/tmp/x.go:12:13: note: expanded from macro 'int'
#define int asdf
^
2 errors generated.
The two marked lines used to refer incorrectly to /tmp/x.go.
Fixes#15836.
Change-Id: I08ef60a53cfd148112fceb651eaf7b75d94a7a8d
Reviewed-on: https://go-review.googlesource.com/32613
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The pointer checking code needs to know the exact type of the parameter
expected by the C function, so that it can use a type assertion to
convert the empty interface returned by cgoCheckPointer to the correct
type. Previously this was done by using a type conversion, but that
meant that the code accepted arguments that were convertible to the
parameter type, rather than arguments that were assignable as in a
normal function call. In other words, some code that should not have
passed type checking was accepted.
This CL changes cgo to always use a function literal for pointer
checking. Now the argument is passed to the function literal, which has
the correct argument type, so type checking is performed just as for a
function call as it should be.
Since we now always use a function literal, simplify the checking code
to run as a statement by itself. It now no longer needs to return a
value, and we no longer need a type assertion.
This does have the cost of introducing another function call into any
call to a C function that requires pointer checking, but the cost of the
additional call should be minimal compared to the cost of pointer
checking.
Fixes#16591.
Change-Id: I220165564cf69db9fd5f746532d7f977a5b2c989
Reviewed-on: https://go-review.googlesource.com/31233
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When we need to generate a call to _cgoCheckPointer, we need to type
assert the result back to the desired type. That is harder when the type
is unsafe.Pointer, as the package can have values of unsafe.Pointer
types without actually importing unsafe, by mixing C void* and :=. We
used to handle this by generating a special function for each needed
type, and defining that function in a separate file where we did import
unsafe.
Simplify the code by not generating those functions, but instead just
import unsafe under the alias _cgo_unsafe. This is a simplification step
toward a fix for issue #16591.
Change-Id: I0edb3e04b6400ca068751709fe063397cf960a54
Reviewed-on: https://go-review.googlesource.com/30973
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
complex64 and complex128 are treated like [2]float32 and [2]float64,
so it makes sense to align them the same way.
Change-Id: Ic614bcdcc91b080aeb1ad1fed6fc15ba5a2971f8
Reviewed-on: https://go-review.googlesource.com/19800
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Don't write line info for types, we don't have it.
Otherwise types look like:
type _Ctype_struct_cb struct {
//line :1
on_test *[0]byte
//line :1
}
Which is not useful. Moreover we never override source info,
so subsequent source code uses the same source info.
Moreover, empty file name makes compile emit no source debug info at all.
Update #17190
Change-Id: I7ae6fa4964520d7665743d340419b787df0b51e8
Reviewed-on: https://go-review.googlesource.com/29713
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The combination of https://golang.org/cl/23650 and
https://golang.org/cl/23675 did not work--they were tested separately
but not together.
The problem was that 23650 introduced deferred argument checking, and
the deferred function loses the type that 23675 started requiring. The
fix is to go back to using an empty interface type in a deferred
argument check.
No new test required--fixes broken build.
Change-Id: I5ea023c5aed71d70e57b11c4551242d3ef25986d
Reviewed-on: https://go-review.googlesource.com/23961
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When cgo writes a _cgoCheckPointerN function to handle unsafe.Pointer,
use the function's argument type rather than interface{}. This permits
type errors to be detected at build time rather than run time.
Fixes#13830.
Change-Id: Ic7090905e16b977e2379670e0f83640dc192b565
Reviewed-on: https://go-review.googlesource.com/23675
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Add TSAN acquire/release calls to runtime/cgo to match the ones
generated by cgo. This avoids a false positive race around the malloc
memory used in runtime/cgo when other goroutines are simultaneously
calling malloc and free from cgo.
These new calls will only be used when building with CGO_CFLAGS and
CGO_LDFLAGS set to -fsanitize=thread, which becomes a requirement to
avoid all false positives when using TSAN. These are needed not just
for runtime/cgo, but also for any runtime package that uses cgo (such as
net and os/user).
Add an unused attribute to the _cgo_tsan_acquire and _cgo_tsan_release
functions, in case there are no actual cgo function calls.
Add a test that checks that setting CGO_CFLAGS/CGO_LDFLAGS avoids a
false positive report when using os/user.
Change-Id: I0905c644ff7f003b6718aac782393fa219514c48
Reviewed-on: https://go-review.googlesource.com/23492
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Acquire and release the TSAN synchronization point when calling malloc,
just as we do when calling any other C function. If we don't do this,
TSAN will report false positive errors about races calling malloc and
free.
We used to have a special code path for malloc and free, going through
the runtime functions cmalloc and cfree. The special code path for cfree
was no longer used even before this CL. This CL stops using the special
code path for malloc, because there is no place along that path where we
could conditionally insert the TSAN synchronization. This CL removes
the support for the special code path for both functions.
Instead, cgo now automatically generates the malloc function as though
it were referenced as C.malloc. We need to automatically generate it
even if C.malloc is not called, even if malloc and size_t are not
declared, to support cgo-provided functions like C.CString.
Change-Id: I829854ec0787a80f33fa0a8a0dc2ee1d617830e2
Reviewed-on: https://go-review.googlesource.com/23260
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When the generated stub functions write back the results to the stack,
they can in some cases be writing to the same memory on the g0 stack.
There is no race here (assuming there is no race in the Go code), but
the thread sanitizer does not know that. Turn off the thread sanitizer
for the stub functions to prevent false positive warnings.
Current clang suggests the no_sanitize("thread") attribute, but that
does not work with clang 3.6 or GCC. clang 3.6, GCC, and current clang
all support the no_sanitize_thread attribute, so use that
unconditionally.
The test case and first version of the patch are from Dmitriy Vyukov.
Change-Id: I80ce92824c6c8cf88ea0fe44f21cf50cf62474c9
Reviewed-on: https://go-review.googlesource.com/23252
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The //extern comments are incorrect and cause undefined symbol
errorswhen building cgo code with -compiler=gccgo. The code is already
designed to use weak references, and that support relies on the cgo
check functions being treated as local functions.
Change-Id: Ib38a640cc4ce6eba74cfbf41ba7147ec88769ec0
Reviewed-on: https://go-review.googlesource.com/23014
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
GCC, unlike clang, does not provide any way for code being compiled to tell if
-fsanitize-thread was passed. But cgo can look to see if that flag is being
passed and generate different code in that case.
Fixes#14602
Change-Id: I86cb5318c2e35501ae399618c05af461d1252d2d
Reviewed-on: https://go-review.googlesource.com/22688
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I got a complaint that cgo output triggers warnings with
-Wdeclaration-after-statement. I don't think it's worth testing for
this--C has permitted declarations after statements since C99--but it is
easy enough to fix. It may break again; so it goes.
This CL also fixes errno handling to avoid getting confused if the tsan
functions happen to change the global errno variable.
Change-Id: I0ec7c63a6be5653ef44799d134c8d27cb5efa441
Reviewed-on: https://go-review.googlesource.com/22686
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add support for the context function set by runtime.SetCgoTraceback.
The context function was added in CL 17761, without support.
This CL is the support.
This CL has not been tested for real C code, as a working context
function for C code requires unwind support that does not seem to exist.
I wanted to get the CL out before the freeze.
I apologize for the length of this CL. It's mostly plumbing, but
unfortunately the plumbing is processor-specific.
Change-Id: I8ce11a0de9b3dafcc29efd2649d776e93bff0e90
Reviewed-on: https://go-review.googlesource.com/22508
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add a C.CBytes function to copy a Go byte slice into C memory. This
returns an unsafe.Pointer, since that is what needs to be passed to
C.free, and the data is often opaque bytes anyway.
Fixes#14838
Change-Id: Ic7bc29637eb6f1f5ee409b3898c702a59833a85a
Reviewed-on: https://go-review.googlesource.com/20762
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The tree's pretty inconsistent about single space vs double space
after a period in documentation. Make it consistently a single space,
per earlier decisions. This means contributors won't be confused by
misleading precedence.
This CL doesn't use go/doc to parse. It only addresses // comments.
It was generated with:
$ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])')
$ go test go/doc -update
Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7
Reviewed-on: https://go-review.googlesource.com/20022
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a subset of https://golang.org/cl/20022 with only the copyright
header lines, so the next CL will be smaller and more reviewable.
Go policy has been single space after periods in comments for some time.
The copyright header template at:
https://golang.org/doc/contribute.html#copyright
also uses a single space.
Make them all consistent.
Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0
Reviewed-on: https://go-review.googlesource.com/20111
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add writeback code to each return location which copies
the final result back to the correct stack location.
Cgo plays tricky games by taking the address of a
in f(a int) (b int) and then using that address to
modify b. So for cgo-generated Go code, disable the
SSAing of output args.
Update #14511
Change-Id: I95cba727d53699d31124eef41db0e03935862be9
Reviewed-on: https://go-review.googlesource.com/19988
Reviewed-by: Todd Neal <todd@tneal.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When Go code is used with C code compiled with -fsanitize=thread, adds
thread sanitizer calls so that correctly synchronized Go code does not
cause spurious failure reports from the thread sanitizer. This may
cause some false negatives, but for the thread sanitizer what is most
important is avoiding false positives.
Change-Id: If670e4a6f2874c7a2be2ff7db8728c6036340a52
Reviewed-on: https://go-review.googlesource.com/17421
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
This uses weak declarations so that it will work with current versions
of gccgo that do not support pointer checking.
Change-Id: Ia34507e3231ac60517cb6834f0b673764715a256
Reviewed-on: https://go-review.googlesource.com/17429
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
(instead of using a GCC extension).
Change-Id: I110dc45bfe5f1377fe3453070eccde283b5cc161
Reviewed-on: https://go-review.googlesource.com/17716
Reviewed-by: Russ Cox <rsc@golang.org>
This makes it more convenient for C code to use GoString with string
constants. Since Go string values are immutable, the const qualifier is
appropriate in C.
Change-Id: I5fb3cdce2ce5079f1f0467a1544bb3a1eb27b811
Reviewed-on: https://go-review.googlesource.com/17067
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
In the past, cgo generated Go code and C code. The C code was linked
into a shared library. The Go code was built into an executable that
dynamically linked against that shared library. C wrappers were
exported from the shared library, and the Go code called them.
It was all a long time ago, but in order to permit C code to call back
into Go, somebody implemented #pragma dynexport (https://golang.org/cl/661043)
to export a Go symbol into the dynamic symbol table. Then that same
person added code to cgo to recognize //export comments
(https://golang.org/cl/853042). The //export comments were implemented
by generating C code, to be compiled by GCC, that would refer to C code,
to be compiled by 6c, that would call the Go code. The GCC code would
go into a shared library. The code compiled by 6c would be in the Go
executable. The GCC code needed to refer to the 6c code, so the 6c
function was marked with #pragma dynexport. The important point here is
that #pragma dynexport was used to expose an internal detail of the
implementation of an exported function, because at the time it was
necessary.
Moving forward to today, cgo no longer generates a shared library and 6c
no longer exists. It's still true that we have a function compiled by
GCC that refers to a wrapper function now written in Go. In the normal
case today we are doing an external link, and we use a
//go:cgo_export_static function to make the Go wrapper function visible
to the C code under a known name.
The #pragma dynexport statement has become a //go:cgo_export_dynamic
comment on the Go code. That comment only takes effect when doing
internal linking. The comment tells the linker to put the symbol in the
dynamic symbol table. That still makes sense for the now unusual case
of using internal linking with a shared library.
However, all the changes to this code have carefully preserved the
property that the //go:cgo_export_dynamic comment refers to an internal
detail of the implementation of an exported function. That was
necessary a long time ago, but no longer makes sense.
This CL changes the code to put the actual C-callable function into the
dynamic symbol table. I considered dropping the comment entirely, but
it turns out that there is even a test for this, so I preserved it.
Change-Id: I66a7958e366e5974363099bfaa6ba862ca327849
Reviewed-on: https://go-review.googlesource.com/17061
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
This implements part of the proposal in issue 12416 by adding dynamic
checks for passing pointers from Go to C. This code is intended to be
on at all times. It does not try to catch every case. It does not
implement checks on calling Go functions from C.
The new cgo checks may be disabled using GODEBUG=cgocheck=0.
Update #12416.
Change-Id: I48de130e7e2e83fb99a1e176b2c856be38a4d3c8
Reviewed-on: https://go-review.googlesource.com/16003
Reviewed-by: Russ Cox <rsc@golang.org>
The code works without the newline, but it looks funny:
func _cgoexp_15afe6549f62_GoFn(a unsafe.Pointer, n int32) { fn := GoFn
This adds a newline after the '{'.
Change-Id: I6c465abe16f47924426d1b22b91004b3a3586ebd
Reviewed-on: https://go-review.googlesource.com/16612
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When exporting a function using gccgo, we generate two functions: a Go
function with a leading Cgoexp_ prefix, and a C function that calls the
Go function. The Go function has a name that can not be represented in
C, so the C code needs a declaration with an __asm__ qualifier giving
the name of the Go function.
Before this CL we put that declaration in the exported header file.
Because code would sometimes #include "_cgo_export.h", we added a macro
definition for the C function giving it the name of the declaration. We
then added a macro undefine in the actual C code, so that we could
declare the C function we wanted.
This rounadabout process worked OK until we started exporting the header
file for use with -buildmode=c-archive and c-shared. Doing that caused
the code to see the define and thus call the Go function rather than the
C function. That often works fine, but the C function calls
_cgo_wait_runtime_init_done before calling the Go function, and that
sometimes matters. This didn't show up in tests because we don't test
using gccgo. That is something we should fix, but not now.
Fix that by simplifying the code to declare the C function in the header
file as one would expect, and move the __asm__ declaration to the C
code.
Change-Id: I33547e028152ff98e332630994b4f33285feec32
Reviewed-on: https://go-review.googlesource.com/15043
Reviewed-by: Minux Ma <minux@golang.org>
If an exported function has named return variables, then show the names
as comments in the return struct we create in the header file.
Example here:
https://groups.google.com/forum/#!topic/golang-nuts/r393ne4zIfY
Change-Id: I21fb4ca2673f6977bec35ccab0cef7d42b311f96
Reviewed-on: https://go-review.googlesource.com/13061
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Some routines run without and m or g and cannot invoke the
race detector runtime. They must be opaque to the runtime.
That used to be true because they were written in C.
Now that they are written in Go, disable the race detector
annotations for those functions explicitly.
Add test.
Fixes#10874.
Change-Id: Ia8cc28d51e7051528f9f9594b75634e6bb66a785
Reviewed-on: https://go-review.googlesource.com/12534
Reviewed-by: Ian Lance Taylor <iant@golang.org>
