Clang does not record the "size" field for pointer types,
so we must insert the size ourselves. We were already
doing this, but only for the case of pointer types.
For an array of pointer types, the setting of the size for
the nested pointer type was happening after the computation
of the size of the array type, meaning that the array type
was always computed as 0 bytes. Delay the size computation.
This bug happens on all Clang systems, not just FreeBSD.
Our test checked that cgo wrote something, not that it was correct.
FreeBSD's default clang rejects array[0] as a C struct field,
so it noticed the incorrect sizes. But the sizes were incorrect
everywhere.
Update testcdefs to check the output has the right semantics.
Fixes#6292.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/22840043
The old approach to determining whether "name" was a type, constant,
or expression was to compile the C program
name;
and scan the errors and warnings generated by the compiler.
This requires looking for specific substrings in the errors and warnings,
which ties the implementation to specific compiler versions.
As compilers change their errors or drop warnings, cgo breaks.
This happens slowly but it does happen.
Clang in particular (now required on OS X) has a significant churn rate.
The new approach compiles a slightly more complex program
that is either valid C or not valid C depending on what kind of
thing "name" is. It uses only the presence or absence of an error
message on a particular line, not the error text itself. The program is:
// error if and only if name is undeclared
void f1(void) { typeof(name) *x; }
// error if and only if name is not a type
void f2(void) { name *x; }
// error if and only if name is not an integer constant
void f3(void) { enum { x = (name)*1 }; }
I had not been planning to do this until Go 1.3, because it is a
non-trivial change, but it fixes a real Xcode 5 problem in Go 1.2,
and the new code is easier to understand than the old code.
It should be significantly more robust.
Fixes#6596.
Fixes#6612.
R=golang-dev, r, james, iant
CC=golang-dev
https://golang.org/cl/15070043
Ensure that clang always exits with a non-zero status by
giving it something that it always warns about (the statement "1;").
Fixes#6128.
R=golang-dev, iant, minux.ma
CC=golang-dev
https://golang.org/cl/14702043
Fixes a bug in cgo on OS X using clang.
See golang.org/issue/6472 for details.
Fixes#6472.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/14575043
Because we can, and because it otherwise might crash
the program if we think we're out of memory.
Fixes#6390.
R=golang-dev, iant, minux.ma
CC=golang-dev
https://golang.org/cl/13345048
This is not quite what that issue reports,
because this does not involve a DLL.
But I wanted to make sure this much was working.
Update #4339
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/13653043
* Add a new kind of Name, "fpvar" which stands for function pointer variable
* When walking the AST, find functions used as expressions and create a new Name object for them
* Track functions which are only used in expr contexts, and avoid generating bridge code for them
R=golang-dev, minux.ma, fullung, rsc, iant
CC=golang-dev
https://golang.org/cl/9835047
Basically a partial rollback of 12053043 until I can
figure out what is really going on.
Fixes bug 6051.
R=golang-dev
CC=golang-dev
https://golang.org/cl/12496043
Split stack checks (morestack) corrupt g->sched,
but g->sched must be preserved consistent for GC/traceback.
The change implements runtime.notetsleepg function,
which does entersyscall/exitsyscall and is carefully arranged
to not call any split functions in between.
R=rsc
CC=golang-dev
https://golang.org/cl/11575044
Don't require a full-scale callback for calls to the special
prologue functions.
Always use a simple wrapper function for C functions, so that
we can handle static functions defined in the import "C"
comment.
Disable a test that relies on gc-specific function names.
Fixes#5905.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/11406047
The problem is that the cdecl() function in cmd/cgo/godefs.go isn't
properly translating the Go array type to a C array type when an
asterisk follows the [] in the array type declaration (it is perfectly
legal to put the asterisk on either side of the [] in go syntax,
depending on how you set up your pointers).
That said, the cdefs tool is only designed to translate from Go types
generated using the cgo *godefs* tool -- where the godefs tool is
designed to translate gcc-style C types into Go types. In essence, the
cdefs tool translates from gcc-style C types to Go types (via the godefs
tool), then back to kenc-style C types. Because of this, cdefs does not
need to know how to translate arbitraty Go types into C, just the ones
produced by godefs.
The problem is that during this translation process, the logic is
slightly wrong when going from (e.g.):
char *array[10];
to:
array [10]*int8;
back to:
int8 *array[10];
In the current implementation of cdecl(), the translation from the Go
type declaration back to the kenc-style declaration looks for Go
types of the form:
name *[]type;
rather than the actual generated Go type declaration of:
name []*type;
Both are valid Go syntax, with slightly different semantics, but the
latter is the only one that can ever be generated by the godefs tools.
(The semantics of the former are not directly expressible in a
single C statement -- you would have to have to first typedef the array
type, then declare a pointer to that typedef'd type in a separate
statement).
This commit changes the logic of cdecl() to look properly for, and
translate, Go type declarations of the form:
name []*type;
Additionally, the original implementation only allowed for a single
asterisk and a single sized aray (i.e. only a single level of pointer
indirection, and only one set of []) on the type, whereas the patched
version allows for an arbitrary number of both.
Tests are included in misc/cgo/testcdefs and the all.bash script has been
updated to account for these.
R=golang-dev, bradfitz, dave, iant
CC=golang-dev
https://golang.org/cl/11377043
The static func named thread in issue5337.go's C snippet
conflicts with the static func named thread in issue3350.go's C snippet.
I don't know why (they're both static) but I also don't care,
because -linkmode=internal only needs to be able to handle
the cgo in the standard library, and it does.
Change the test to avoid this problem.
Fixes build (after run.bash is fixed to detect the breakage).
R=minux.ma
TBR=minux.ma
CC=golang-dev
https://golang.org/cl/11201043
Add gostartcall and gostartcallfn.
The old gogocall = gostartcall + gogo.
The old gogocallfn = gostartcallfn + gogo.
R=dvyukov, minux.ma
CC=golang-dev
https://golang.org/cl/10036044
runtime.setmg() calls another function (cgo_save_gm), so it must save
LR onto stack.
Re-enabled TestCthread test in misc/cgo/test.
Fixes#4863.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/9019043
This change removes processing of #cgo directives from cmd/cgo,
pushing the onus back on cmd/go to pass all necessary flags.
Fixes#5224. See comments for rationale.
R=golang-dev, iant, r
CC=golang-dev
https://golang.org/cl/8610044
Some variables declared in C could end up as undefined symbols
in the final binary and have null address.
Fixes#5114.
Fixes#5227.
R=golang-dev, iant, ajstarks, dave, r
CC=golang-dev
https://golang.org/cl/8602044
This CL was written by rsc. I just tweaked 8l.
This CL adds TLS relocation to the ELF .o file we write during external linking,
so that the host linker (gcc) can decide the final location of m and g.
Similar relocations are not necessary on OS X because we use an alternate
program start-time mechanism to acquire thread-local storage.
Similar relocations are not necessary on ARM or Plan 9 or Windows
because external linking mode is not yet supported on those systems.
On almost all ELF systems, the references we use are like %fs:-0x4 or %gs:-0x4,
which we write in 6a/8a as -0x4(FS) or -0x4(GS). On Linux/ELF, however,
Xen's lack of support for this mode forced us long ago to use a two-instruction
sequence: first we load %gs:0x0 into a register r, and then we use -0x4(r).
(The ELF program loader arranges that %gs:0x0 contains a regular pointer to
that same memory location.) In order to relocate those -0x4(r) references,
the linker must know where they are. This CL adds the equivalent notation
-0x4(r)(GS*1) for this purpose: it assembles to the same encoding as -0x4(r)
but the (GS*1) indicates to the linker that this is one of those thread-local
references that needs relocation.
Thanks to Elias Naur for reminding me about this missing piece and
also for writing the test.
R=r
CC=golang-dev
https://golang.org/cl/7891047
The arm gentraceback mishandled frame linkage values pointing
to the assembly return function. This function is special as
its frame size is zero and it contains only one instruction.
These conditions would preserve the frame pointer and result
in an off by one error when unwinding the caller.
Fixes#5124
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8023043
