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>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
This will make it possible for C++ code to #include the export header
file and see the correct declarations.
The preamble remains the user's responsibility. It would not be
appropriate to wrap the preamble in extern "C", because it might
include header files that work with both C and C++. Putting those
header files in an extern "C" block would break them.
Change-Id: Ifb40879d709d26596d5c80b1307a49f1bd70932a
Reviewed-on: https://go-review.googlesource.com/9850
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The -exportheader option tells cgo to generate a header file declaring
expoted functions. The header file is only created if there are, in
fact, some exported functions, so it also serves as a signal as to
whether there were any.
In future CLs the go tool will use this option to install header files
for packages that use cgo and export functions.
Change-Id: I5b04357d453a9a8f0e70d37f8f18274cf40d74c9
Reviewed-on: https://go-review.googlesource.com/9796
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also copy doc comments from Go code to _cgo_export.h.
This is a step toward installing this generated file when using
-buildmode=c-archive or c-shared, so that C code can #include it.
Change-Id: I3a243f7b386b58ec5c5ddb9a246bb9f9eddc5fb8
Reviewed-on: https://go-review.googlesource.com/9790
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This extends the cgo changes in http://golang.org/cl/8094 to gccgo.
It also adds support for setting runtime_iscgo correctly for gccgo;
the gc runtime bases the variable on the runtime/cgo package, but
gccgo has no equivalent to that package.
The go tool supports -buildmode=c-archive for gccgo by linking all the
Go objects together using -r. For convenience this object is then put
into an archive file.
The go tool now passes -fsplit-stack when building C code for gccgo on
386 and amd64. This is required for using -r and will also cut down
on unnecessary stack splits.
The go tool no longer applies standard package cgo LDFLAGS when using
gccgo. This is mainly to avoid getting confused by the LDFLAGS in the
runtime/cgo package that gccgo does not use.
Change-Id: I1d0865b2a362818a033ca9e9e901d0ce250784e7
Reviewed-on: https://go-review.googlesource.com/9511
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is Part 2 of the change, see Part 1 here: in https://go-review.googlesource.com/#/c/7692/
Suggested by iant@, we use the library initialization entry point to:
- create a new OS thread and run the "regular" runtime init stack on
that thread
- return immediately from the main (i.e., loader) thread
- at the first CGO invocation, we wait for the runtime initialization
to complete.
The above mechanism is implemented only on linux_amd64. Next step is to
support it on linux_arm. Other platforms don't yet support shared library
compiling/linking, but we intend to use the same strategy there as well.
Change-Id: Ib2c81b1b83bee837134084b75a3beecfb8de6bf4
Reviewed-on: https://go-review.googlesource.com/8094
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This implements support for calls to and from C in the ppc64 C ABI, as
well as supporting functionality such as an entry point from the
dynamic linker.
Change-Id: I68da6df50d5638cb1a3d3fef773fb412d7bf631a
Reviewed-on: https://go-review.googlesource.com/2009
Reviewed-by: Russ Cox <rsc@golang.org>
The gc toolchain no longer includes a C compiler, so mentions of "6c"
can be removed or replaced by 6g as appropriate. Similarly, some cgo
functions that previously generated C source output no longer need to.
Change-Id: I1ae6b02630cff9eaadeae6f3176c0c7824e8fbe5
Reviewed-on: https://go-review.googlesource.com/2391
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Instead of relying on the asm names declared in the gccgo version of
cgo_export.h, just emit a dummy symbol with the right asm name. This
is enough to let the _cgo_main link succeed, which is all that matters
here.
Fixes#9294.
Change-Id: I803990705b6b226ed0adf17dc57b58a9f501b213
Reviewed-on: https://go-review.googlesource.com/1901
Reviewed-by: Minux Ma <minux@golang.org>
[This CL is part of the removal of C code from package runtime.
See golang.org/s/dev.cc for an overview.]
We changed cgo to write the actual function wrappers in Go
for Go 1.4. The only code left in C output files was the definitions
for pointers to C data and the #pragma cgo directives.
Write both of those to Go outputs instead, using the new
compiler directives introduced in CL 169360043.
(Still generating C files in gccgo mode.)
LGTM=r
R=r
CC=austin, golang-codereviews, iant, khr
https://golang.org/cl/169330045
Need to restore the g register. Somehow this line vaporized from
CL 144130043. Also cgo_topofstack -> _cgo_topofstack, that vaporized also.
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/150940044
During a cgo call, the stack can be copied. This copy invalidates
the pointer that cgo has into the return value area. To fix this
problem, pass the address of the location containing the stack
top value (which is in the G struct). For cgo functions which
return values, read the stktop before and after the cgo call to
compute the adjustment necessary to write the return value.
Fixes#8771
LGTM=iant, rsc
R=iant, rsc, khr
CC=golang-codereviews
https://golang.org/cl/144130043
In linker, refuse to write conservative (array of pointers) as the
garbage collection type for any variable in the data/bss GC program.
In the linker, attach the Go type to an already-read C declaration
during dedup. This gives us Go types for C globals for free as long
as the cmd/dist-generated Go code contains the declaration.
(Most runtime C declarations have a corresponding Go declaration.
Both are bss declarations and so the linker dedups them.)
In cmd/dist, add a few more C files to the auto-Go-declaration list
in order to get Go type information for the C declarations into the linker.
In C compiler, mark all non-pointer-containing global declarations
and all string data as NOPTR. This allows them to exist in C files
without any corresponding Go declaration. Count C function pointers
as "non-pointer-containing", since we have no heap-allocated C functions.
In runtime, add NOPTR to the remaining pointer-containing declarations,
none of which refer to Go heap objects.
In runtime, also move os.Args and syscall.envs data into runtime-owned
variables. Otherwise, in programs that do not import os or syscall, the
runtime variables named os.Args and syscall.envs will be missing type
information.
I believe that this CL eliminates the final source of conservative GC scanning
in non-SWIG Go programs, and therefore...
Fixes#909.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/149770043
Instead of including <sys/types.h> to get size_t, instead include
the ISO C standard <stddef.h> header, which defines fewer additional
types at risk of colliding with the user code. In particular, this
prevents collisions between <sys/types.h>'s userspace definitions with
the kernel definitions needed by defs_linux.go.
Also, -cdefs mode uses #pragma pack, so we can keep misaligned fields.
Fixes#8477.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/120610043
Breaks build for FreeBSD. Probably clang related?
««« original CL description
cmd/cgo: disable inappropriate warnings when the gcc struct is empty
package main
//#cgo CFLAGS: -Wall
//void test() {}
import "C"
func main() {
C.test()
}
This code will cause gcc issuing warnings about unused variable.
This commit use offset of the second return value of
Packages.structType to detect whether the gcc struct is empty,
and if it's directly invoke the C function instead of writing an
unused code.
LGTM=dave, minux
R=golang-codereviews, iant, minux, dave
CC=golang-codereviews
https://golang.org/cl/109640045
»»»
TBR=dfc
R=dave
CC=golang-codereviews
https://golang.org/cl/114990044
package main
//#cgo CFLAGS: -Wall
//void test() {}
import "C"
func main() {
C.test()
}
This code will cause gcc issuing warnings about unused variable.
This commit use offset of the second return value of
Packages.structType to detect whether the gcc struct is empty,
and if it's directly invoke the C function instead of writing an
unused code.
LGTM=dave, minux
R=golang-codereviews, iant, minux, dave
CC=golang-codereviews
https://golang.org/cl/109640045
For gccgo we rename exported functions so that the compiler
will make them visible. This CL adds a #define so that C
functions that #include "cgo_export.h" can use the expected
names of the function.
The test for this is the existing issue6833 test in
misc/cgo/test. Without this CL it fails when using
-compiler=gccgo.
LGTM=minux.ma, rsc
R=golang-codereviews, gobot, rsc, minux.ma
CC=golang-codereviews
https://golang.org/cl/91830046
Previously we used strndup(3) to implement C.CString for gccgo. This
is wrong because strndup assumes the string to be null terminated,
and stops at the first null terminator. Instead, use malloc
and memmove to create a copy of the string, as we do in the
gc implementation.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/96790047
Use the symbol prefixes with the prologue functions when using
gccgo.
Use an & when referring to a function declared as a variable.
Fix the malloc prologue function.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/13878043
