Fixes#13930.
Change-Id: I124b7d31d1f2be05b7f23dafd1e52d9f3f02f3f0
Reviewed-on: https://go-review.googlesource.com/18623
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It doesn't work there ("out of memory") and doesn't really matter.
Fixes build (now that we enable cgo on the darwin/386 builder.)
Change-Id: I1d91e51ecb88c54eae39ac9a76f2c0b4e45263b0
Reviewed-on: https://go-review.googlesource.com/19004
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Apparently the darwin/386 builder does not enable cgo.
This failure turned up running
GOARCH=386 GOHOSTARCH=386 ./all.bash
on my Mac.
Change-Id: Ia2487c4fd85d4b0f9f564880f22d9fde379946c3
Reviewed-on: https://go-review.googlesource.com/18859
Reviewed-by: Ian Lance Taylor <iant@golang.org>
[Repeat of CL 18343 with build fixes.]
Before, NumGoroutine counted system goroutines and Stack (usually) didn't show them,
which was inconsistent and confusing.
To resolve which way they should be consistent, it seems like
package main
import "runtime"
func main() { println(runtime.NumGoroutine()) }
should print 1 regardless of internal runtime details. Make it so.
Fixes#11706.
Change-Id: If26749fec06aa0ff84311f7941b88d140552e81d
Reviewed-on: https://go-review.googlesource.com/18432
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
If non-Go code calls sigaltstack before a signal is received, use
sigaltstack to determine the current signal stack and set the gsignal
stack to use it. This makes the Go runtime more robust in the face of
non-Go code. We still can't handle a disabled signal stack or a signal
triggered with SA_ONSTACK clear, but we now give clear errors for those
cases.
Fixes#7227.
Update #9896.
Change-Id: Icb1607e01fd6461019b6d77d940e59b3aed4d258
Reviewed-on: https://go-review.googlesource.com/18102
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
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>
This also fixes an unintended behavior where C's "complex float" and
"complex double" types were interchangeable with Go's "complex64" and
"complex128" types.
Fixes#13402.
Change-Id: I73f96d9a4772088d495073783c6982e9634430e8
Reviewed-on: https://go-review.googlesource.com/17208
Reviewed-by: Ian Lance Taylor <iant@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>
Change the linker to use a copy of the C compiler support library,
libgcc.a, when doing internal linking. This will be used to satisfy any
undefined symbols referenced by host objects.
Change the dist tool to copy the support library into a new directory
tree under GOROOT/pkg/libgcc. This ensures that libgcc is available
even when building Go programs on a system that has no C compiler. The
C compiler is required when building the Go installation in the first
place, but is not required thereafter.
Change the go tool to not link libgcc into cgo objects.
Correct the linker handling of a weak symbol in an ELF input object to
not always create a new symbol, but to use an existing symbol if there
is one; this is necessary on freebsd-amd64, where libgcc contains a weak
definition of compilerrt_abort_impl.
Fixes#9510.
Change-Id: I1ab28182263238d9bcaf6a42804e5da2a87d8778
Reviewed-on: https://go-review.googlesource.com/16741
Reviewed-by: Russ Cox <rsc@golang.org>
When using gccgo it's OK if a pointer passed to C remains on the stack.
Gccgo does not have the clear distinction between C and Go stacks.
Change-Id: I3af9dd6fe078214ab16d9d8dad2d206608d7891d
Reviewed-on: https://go-review.googlesource.com/16774
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@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>
This is, in effect, what the gc toolchain does. It fixes cases where Go
code refers to a C global variable; without this, if the global variable
was the only thing visible in the C code, the generated cgo file might
not get pulled in from the archive, leaving the Go variable
uninitialized.
This was reported against gccgo as https://gcc.gnu.org/PR68255 .
Change-Id: I3e769dd174f64050ebbff268fbbf5e6fab1e2a1b
Reviewed-on: https://go-review.googlesource.com/16775
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Replace the confusing game where a frame size of $-8 would suppress the
implicit setting up of a stack frame with a nice explicit flag.
The code to set up the function prologue is still a little confusing but better
than it was.
Change-Id: I1d49278ff42c6bc734ebfb079998b32bc53f8d9a
Reviewed-on: https://go-review.googlesource.com/15670
Reviewed-by: Minux Ma <minux@golang.org>
Fixes these warnings from go vet:
buildid_linux.go:25: no formatting directive in Fatalf call
callback.go:180: arg pc[i] for printf verb %p of wrong type: uintptr
env.go:34: possible misuse of unsafe.Pointer
issue7665.go:22: possible misuse of unsafe.Pointer
Change-Id: I83811b9c10c617139713a626b4a34ab05564d4fe
Reviewed-on: https://go-review.googlesource.com/15802
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Glibc uses some special signals for special thread operations. These
signals will be used in programs that use cgo and invoke certain glibc
functions, such as setgid. In order for this to work, these signals
need to not be masked by any thread. Before this change, they were
being masked by programs that used os/signal.Notify, because it
carefully masks all non-thread-specific signals in all threads so that a
dedicated thread will collect and report those signals (see ensureSigM
in signal1_unix.go).
This change adds the two glibc special signals to the set of signals
that are unmasked in each thread.
Fixes#12498.
Change-Id: I797d71a099a2169c186f024185d44a2e1972d4ad
Reviewed-on: https://go-review.googlesource.com/14297
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It's because runtime links to ntdll, and ntdll exports a couple
incompatible libc functions. We must link to msvcrt first and
then try ntdll.
Fixes#12030.
Change-Id: I0105417bada108da55f5ae4482c2423ac7a92957
Reviewed-on: https://go-review.googlesource.com/14472
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In order to fix issue #9401 the compiler was changed to add a padding
byte to any non-empty Go struct that ends in a zero-sized field. That
causes the Go version of such a C struct to have a different size than
the C struct, which can considerable confusion. Change cgo so that it
discards any such zero-sized fields, so that the Go and C structs are
the same size.
This is a change from previous releases, in that it used to be
possible to refer to a zero-sized trailing field (by taking its
address), and with this change it no longer is. That is unfortunate,
but something has to change. It seems better to visibly break
programs that do this rather than to silently break programs that rely
on the struct sizes being the same.
Update #9401.
Fixes#11925.
Change-Id: I3fba3f02f11265b3c41d68616f79dedb05b81225
Reviewed-on: https://go-review.googlesource.com/12864
Reviewed-by: Russ Cox <rsc@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>
Fix build error when CL=clang introduced by CL 10173.
Change-Id: I8edf210787a9803280c0779ff710c7e634a820d6
Reviewed-on: https://go-review.googlesource.com/10341
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian proposed an improved way of handling signals masks in Go, motivated
by a problem where the Android java runtime expects certain signals to
be blocked for all JVM threads. Discussion here
https://groups.google.com/forum/#!topic/golang-dev/_TSCkQHJt6g
Ian's text is used in the following:
A Go program always needs to have the synchronous signals enabled.
These are the signals for which _SigPanic is set in sigtable, namely
SIGSEGV, SIGBUS, SIGFPE.
A Go program that uses the os/signal package, and calls signal.Notify,
needs to have at least one thread which is not blocking that signal,
but it doesn't matter much which one.
Unix programs do not change signal mask across execve. They inherit
signal masks across fork. The shell uses this fact to some extent;
for example, the job control signals (SIGTTIN, SIGTTOU, SIGTSTP) are
blocked for commands run due to backquote quoting or $().
Our current position on signal masks was not thought out. We wandered
into step by step, e.g., http://golang.org/cl/7323067 .
This CL does the following:
Introduce a new platform hook, msigsave, that saves the signal mask of
the current thread to m.sigsave.
Call msigsave from needm and newm.
In minit grab set up the signal mask from m.sigsave and unblock the
essential synchronous signals, and SIGILL, SIGTRAP, SIGPROF, SIGSTKFLT
(for systems that have it).
In unminit, restore the signal mask from m.sigsave.
The first time that os/signal.Notify is called, start a new thread whose
only purpose is to update its signal mask to make sure signals for
signal.Notify are unblocked on at least one thread.
The effect on Go programs will be that if they are invoked with some
non-synchronous signals blocked, those signals will normally be
ignored. Previously, those signals would mostly be ignored. A change
in behaviour will occur for programs started with any of these signals
blocked, if they receive the signal: SIGHUP, SIGINT, SIGQUIT, SIGABRT,
SIGTERM. Previously those signals would always cause a crash (unless
using the os/signal package); with this change, they will be ignored
if the program is started with the signal blocked (and does not use
the os/signal package).
./all.bash completes successfully on linux/amd64.
OpenBSD is missing the implementation.
Change-Id: I188098ba7eb85eae4c14861269cc466f2aa40e8c
Reviewed-on: https://go-review.googlesource.com/10173
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This doesn't test much with gccgo, but at least it builds now, and the
test does, unsurprisingly, pass. A proper test would require adding
assembly files in GCC syntax for all platforms that gccgo supports,
which would be infeasible.
Also added copyright headers to the asm files.
Change-Id: Icea5af29d7d521a0681506ddb617a79705b76d33
Reviewed-on: https://go-review.googlesource.com/9417
Reviewed-by: Minux Ma <minux@golang.org>
This memory is untyped and can't be used anymore.
The next version of SWIG won't need it.
Change-Id: I592b287c5f5186975ee09a9b28d8efe3b57134e7
Reviewed-on: https://go-review.googlesource.com/8956
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Because there is no libgcc.
Change-Id: I3b3f80791a1db4c2b7318f81a115972cd2237f07
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/8786
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Only documentation / comment changes. Update references to
point to golang.org permalinks or go.googlesource.com/go.
References in historical release notes under doc are left as is.
Change-Id: Icfc14e4998723e2c2d48f9877a91c5abef6794ea
Reviewed-on: https://go-review.googlesource.com/4060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On Darwin/ARM, because libSystem doesn't provide functions for
__sync_fetch_and_add, and only clang can inline that function,
skip the test when building with GCC.
Change-Id: Id5e9d8f9bbe1e6bcb2f381f0f66cf68aa95277c7
Reviewed-on: https://go-review.googlesource.com/2125
Reviewed-by: Ian Lance Taylor <iant@golang.org>
While we're here, rename TestIssue7234 to Test7234 for consistency
with other tests.
Fixes#9557.
Change-Id: I22b0a212b31e7b4f199f6a70deb73374beb80f84
Reviewed-on: https://go-review.googlesource.com/2654
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test is doing pointer graph manipulation from C, and we
cannot support that with concurrent GC. The wbshadow mode
correctly diagnoses missing write barriers.
Disable the test in that mode for now. There is a bigger issue
behind it, namely SWIG, but for now we are focused on making
all.bash pass with wbshadow enabled.
Change-Id: I55891596d4c763e39b74082191d4a5fac7161642
Reviewed-on: https://go-review.googlesource.com/2346
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Use typedmemmove, typedslicecopy, and adjust reflect.call
to execute the necessary write barriers.
Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.
Change-Id: Iec5b5b0c1be5589295e28e5228e37f1a92e07742
Reviewed-on: https://go-review.googlesource.com/2312
Reviewed-by: Keith Randall <khr@golang.org>
For Go 1.5, we can use go:linkname rather than assembly thunk for gc.
Gccgo already has support for //extern.
Change-Id: I5505aa247dd5b555112f7261ed2f192c81cf0bdf
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1888
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
issue9400_linux.go did not build on 386 because it used a constant
that was larger than a 32-bit int in a ... argument. Fix this by
casting the constant to uint64 (to match how the constant is being
used).
Change-Id: Ie8cb64c3910382a41c7852be7734a62f0b2d5a21
Reviewed-on: https://go-review.googlesource.com/2060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These signals are used by glibc to broadcast setuid/setgid to all
threads and to send pthread cancellations. Unlike other signals, the
Go runtime does not intercept these because they must invoke the libc
handlers (see issues #3871 and #6997). However, because 1) these
signals may be issued asynchronously by a thread running C code to
another thread running Go code and 2) glibc does not set SA_ONSTACK
for its handlers, glibc's signal handler may be run on a Go stack.
Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so
this may overflow the Go stack and corrupt heap (or other stack) data.
Fix this by ensuring that these signal handlers have the SA_ONSTACK
flag (but not otherwise taking over the handler).
This has been a problem since Go 1.1, but it's likely that people
haven't encountered it because it only affects setuid/setgid and
pthread_cancel.
Fixes#9600.
Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300
Reviewed-on: https://go-review.googlesource.com/1887
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Gccgo can only get a backtrace for the currently running thread, which
means that it can only get a backtrace for goroutines currently running
Go code. When a goroutine is running C code, gccgo has no way to stop
it and get the backtrace. This test is all about getting a backtrace
of goroutines running C code, so it can't work for gccgo.
Change-Id: I2dff4403841fb544da7396562ab1193875fc14c3
Reviewed-on: https://go-review.googlesource.com/1904
Reviewed-by: Minux Ma <minux@golang.org>
(The assertion depends on a per-package gensym counter whose
value varies based on what else is in the package.)
LGTM=khr
R=khr, rsc
CC=golang-codereviews
https://golang.org/cl/169930043
On heavily loaded build servers, a 5 second timeout is too aggressive,
which causes this test to fail spuriously.
LGTM=iant
R=iant
CC=golang-codereviews, sqweek
https://golang.org/cl/170850043
Our current pe object reader assumes that every symbol starting with
'.' is section. It appeared to be true, until now gcc 4.9.1 generates
some symbols with '.' at the front. Change that logic to check other
symbol fields in addition to checking for '.'. I am not an expert
here, but it seems reasonable to me.
Added test, but it is only good, if tested with gcc 4.9.1. Otherwise
the test PASSes regardless.
Fixes#8811.
Fixes#8856.
LGTM=jfrederich, iant, stephen.gutekanst
R=golang-codereviews, jfrederich, stephen.gutekanst, iant
CC=alex.brainman, golang-codereviews
https://golang.org/cl/152410043
The test doesn't work with GOTRACEBACK != 2.
Diagnose that failure mode.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/152970043
+ static test
NB: there's a preexisting (dynamic) failure of test issue7978.go.
LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/144650045
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
Those C files would have been compiled with 6c.
It's close to impossible to use C correctly anymore,
and the C compilers are going away eventually.
Make them unavailable now.
go1.4.txt change in CL 145890046
LGTM=iant
R=iant
CC=golang-codereviews, r
https://golang.org/cl/149720043
Normally, the caller to runtime.entersyscall() must not return before
calling runtime.exitsyscall(), lest g->syscallsp become a dangling
pointer. runtime.cgocallbackg() violates this constraint. To work around
this, save g->syscallsp and g->syscallpc around cgo->Go callbacks, then
restore them after calling runtime.entersyscall(), which restores the
syscall stack frame pointer saved by cgocall. This allows the GC to
correctly trace a goroutine that is currently returning from a
Go->cgo->Go chain.
This also adds a check to proc.c that panics if g->syscallsp is clearly
invalid. It is not 100% foolproof, as it will not catch a case where the
stack was popped then pushed back beyond g->syscallsp, but it does catch
the present cgo issue and makes existing tests fail without the bugfix.
Fixes#7978.
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, minux, bradfitz, iant, gobot, rsc
CC=golang-codereviews, rsc
https://golang.org/cl/131910043
Now it's two allocations. I don't see much downside to that,
since the two pieces were in different cache lines anyway.
Rename 'conservative' to 'cgo_conservative_type' and make
clear that _cgo_allocate is the only allowed user.
This depends on CL 141490043, which removes the other
use of conservative (in defer).
LGTM=dvyukov, iant
R=khr, dvyukov, iant
CC=golang-codereviews, rlh
https://golang.org/cl/139610043
testSchedLocal* tests need to malloc now because their
stack frames are too big to fit on the G0 stack.
LGTM=iant
R=golang-codereviews, iant, khr
CC=golang-codereviews
https://golang.org/cl/133660043
newstackcall creates a new stack segment, and we want to
be able to throw away all that code.
LGTM=khr
R=khr, iant
CC=dvyukov, golang-codereviews, r
https://golang.org/cl/139270043
If there is doubt about passing arguments correctly
(as there is in this test), there should be doubt about
getting the results back intact too. Using 0 and 1
(especially 0 for success) makes it easy to get a PASS
accidentally when the return value is not actually
being propagated. Use less common values.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/141110043
Instead of making asmcgocall call asmcgocall_errno,
make both load args into registers and call a shared
assembly function.
On amd64, this costs 1 word in the asmcgocall_errno path
but saves 3 words in the asmcgocall path, and the latter
is what happens on critical nosplit paths on Windows.
On arm, this fixes build failures: asmcgocall was writing
the arguments for asmcgocall_errno into the wrong
place on the stack. Passing them in registers avoids the
decision entirely.
On 386, this isn't really needed, since the nosplit paths
have twice as many words to work with, but do it for consistency.
Update #8635
Fixes arm build (except GOARM=5).
TBR=iant
CC=golang-codereviews
https://golang.org/cl/134390043
Clang 3.2 and older (as shipped with OS X Mountain Lion and older)
outputs ambiguous DWARF debug info that makes it impossible for us to
reconstruct accurate type information as required for this test.
Fixes#8611.
LGTM=rsc
R=r, rsc, minux
CC=golang-codereviews
https://golang.org/cl/135990043
In cgo, now that recursive calls to typeConv.Type() always work,
we can more robustly calculate the array sizes based on the size
of our element type.
Also, in debug/dwarf, the decision to call zeroType is made
based on a type's usage within a particular struct, but dwarf.Type
values are cached in typeCache, so the modification might affect
uses of the type in other structs. Current compilers don't appear
to share DWARF type entries for "[]foo" and "[0]foo", but they also
don't consistently share type entries in other cases. Arguably
modifying the types is an improvement in some cases, but varying
translated types according to compiler whims seems like a bad idea.
Lastly, also in debug/dwarf, zeroType only needs to rewrite the
top-level dimension, and only if the rest of the array size is
non-zero.
Fixes#8428.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/127980043
Some systems, like Ubuntu, pass --build-id when linking. The
effect is to put a note in the output file. This is not
useful when generating an object file with the -r option, as
it eventually causes multiple build ID notes in the final
executable, all but one of which are for tiny portions of the
file and are therefore useless.
Disable that by passing an explicit --build-id=none when
linking with -r on systems that might do this.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/119460043
Instead of immediately completing pointer type mappings, add them to
a queue to allow them to be completed later. This fixes issues caused
by Type() returning arbitrary in-progress type mappings.
Fixes#8368.
Fixes#8441.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/122850043
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
If we see a typedef to an anonymous struct more than once,
presumably in two different Go files that import "C", use the
same Go type name.
Fixes#8133.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/102080043
For incomplete struct S, C.T and C.struct_S were interchangeable in Go 1.2
and earlier, because all incomplete types were interchangeable
(even C.struct_S1 and C.struct_S2).
CL 76450043, which fixed issue 7409, made different incomplete types
different from Go's point of view, so that they were no longer completely
interchangeable.
However, imprecision about C.T and C.struct_S - really the same
underlying C type - is the one behavior enabled by the bug that
is most likely to be depended on by existing cgo code.
Explicitly allow it, to keep that code working.
Fixes#7786.
LGTM=iant, r
R=golang-codereviews, iant, r
CC=golang-codereviews
https://golang.org/cl/98580046
If you write:
var x = 3
then the compiler arranges for x to be initialized in the linker
with an actual 3 from the data segment, rather than putting
x in the bss and emitting init-time "x = 3" assignment code.
If you write:
var y = x
var x = 3
then the compiler is clever and treats this the same as if
the code said 'y = 3': they both end up in the data segment
with no init-time assignments.
If you write
var y = x
var x int
then the compiler was treating this the same as if the
code said 'x = 0', making both x and y zero and avoiding
any init-time assignment.
This copying optimization to avoid init-time assignment of y
is incorrect if 'var x int' doesn't mean 'x = 0' but instead means
'x is initialized in C or assembly code'. The program ends up
with 'y = 0' instead of 'y = the value specified for x in that other code'.
Disable the propagation if there is no initializer for x.
This comes up in some uses of cgo, because cgo generates
Go globals that are initialized in accompanying C files.
Fixes#7665.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/93200044
For the gc compiler the Go function Issue7695 is defined in
runtime.c, but there is no way to do that for gccgo, because
there is no way to get the correct pkgpath. The test is not
important for gccgo in any case.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/93870044
Cgo writes C function declarations pretending every arg is a pointer.
If the C function is deferred, it does not inhibit stack copying on split.
The stack copying code believes the C declaration, possibly misinterpreting
integers as pointers.
Probably the right fix for Go 1.3 is to make deferred C functions inhibit
stack copying.
For Go 1.4 and beyond we probably need to make cgo generate Go code
for 6g here, not C code for 6c.
Update #7695
LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/83820043
In external link mode the linker explicitly adds the string
constant "runtime/cgo". It adds the string constant using the
same symbol name as the compiler, but a different format. The
compiler assumes that the string data immediately follows the
string header, but the linker puts the two in different
sections. The result is bad string data when the compiler
sees "runtime/cgo" used as a string constant.
The compiler assumption is in datastring in [568]g/gobj.c.
The linker layout is in addstrdata in ld/data.c. The compiler
assumption is valid for string literals. The linker is not
creating a string literal, so its assumption is also valid.
There are a few ways to avoid this problem. This patch fixes
it by only doing the fake import of runtime/cgo if necessary,
and by only creating the string symbol if necessary.
Fixes#7234.
LGTM=dvyukov
R=golang-codereviews, dvyukov, bradfitz
CC=golang-codereviews
https://golang.org/cl/58410043
NPTL uses SIGRTMIN (signal 32) to effect thread cancellation.
Go's runtime replaces NPTL's signal handler with its own, and
ends up aborting if a C library that ends up calling
pthread_cancel is used.
This patch prevents runtime from replacing NPTL's handler.
Fixes#6997.
R=golang-codereviews, iant, dvyukov
CC=golang-codereviews
https://golang.org/cl/47540043
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 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
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
The ARM implementation of runtime.cgocallback_gofunc diverged
from the calling convention by leaving a word of garbage at
the top of the stack and storing the return PC above the
locals. This change stores the return PC at the top of the
stack and removes the save area above the locals.
Update #5124
This CL fixes first part of the ARM issues and added the unwind test.
R=golang-dev, bradfitz, minux.ma, cshapiro, rsc
CC=golang-dev
https://golang.org/cl/7728045
* Separate internal and external LockOSThread, for cgo safety.
* Show goroutine that made faulting cgo call.
* Never start a panic due to a signal caused by a cgo call.
Fixes#3774.
Fixes#3775.
Fixes#3797.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7228081
Enable cgo on OpenBSD.
The OpenBSD ld.so(1) does not currently support PT_TLS sections. Work
around this by fixing up the TCB that has been provided by librthread
and reallocating a TCB with additional space for TLS. Also provide a
wrapper for pthread_create, allowing zeroed TLS to be allocated for
threads created externally to Go.
Joint work with Shenghou Ma (minux).
Requires change 6846064.
Fixes#3205.
R=golang-dev, minux.ma, iant, rsc, iant
CC=golang-dev
https://golang.org/cl/6853059
compiler_rt introduces a weak and hidden symbol compilerrt_abort_impl
into our pre-linked _all.o object, we have to handle it.
Fixes#4273.
R=iant, rsc, r
CC=golang-dev
https://golang.org/cl/6783050
In a few places, the existing cgo tests assume that a
Go int is the same as a C int. Making int 64 bits wide
on 64-bit platforms violates this assumption.
Change that code to assume that Go int32 and C int
are the same instead. That's still not great, but it's better,
and I am unaware of any systems we run on where it is not true.
Update #2188.
R=iant, r
CC=golang-dev
https://golang.org/cl/6552064
Always process the DWARF info, even when the const value is determined
using the debug data block. This ensures that the injected enum is
removed and future loads of the same constant do not trigger
inconsistent definitions.
Add tests for issues 2470 and 4054.
Fixes#4054.
R=golang-dev, fullung, dave, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6501101
Fixes#4008.
Run a background goroutine that wastes CPU to trick the
power management into raising the CPU frequency which,
by side effect, makes sleep more accurate on arm.
=== RUN TestParallelSleep
--- PASS: TestParallelSleep (1.30 seconds)
_cgo_gotypes.go:772: sleep(1) slept for 1.000458s
R=minux.ma, r
CC=golang-dev
https://golang.org/cl/6498060
This CL adds a step to the build procedure for cgo programs. It uses 'ld -r'
to combine all gcc compiled object file and generate a relocatable object file
for our ld. Additionally, this linking step will combine some static linking
gcc library into the relocatable object file, so that we can use libgcc,
libmingwex and libmingw32 without problem.
Fixes#3261.
Fixes#1741.
Added a testcase for linking in libgcc.
TODO:
1. still need to fix the INDIRECT_SYMBOL_LOCAL problem on Darwin/386.
2. still need to enable the libgcc test on Linux/ARM, because 5l can't deal
with thumb libgcc.
Tested on Darwin/amd64, Darwin/386, FreeBSD/amd64, FreeBSD/386, Linux/amd64,
Linux/386, Linux/ARM, Windows/amd64, Windows/386
R=iant, rsc, bradfitz, coldredlemur
CC=golang-dev
https://golang.org/cl/5822049
1. In CL 5989057, I made a mistake in the last minute change.
"MOVW.W R4, -4(SP)" should really be "MOVW.W R4, -4(R13)",
as 5l will rewrite offset for SP.
2. misc/cgo/test/issue1560.go tests for parallel sleep of 1s,
but on ARM, the deadline is frequently missed, so change sleep
time to 2s on ARM.
R=golang-dev, dave, rsc
CC=golang-dev
https://golang.org/cl/6202043
The last CL forgot the all-important 'backdoor' package.
Cgo-using packages compile .c files with gcc, but we want
to compile this one with 6c, so put it in a non-cgo package.
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/5758063
Also delete gotest, since it's messy to fix and slated for deletion anyway.
A couple of things outside src can't be tested any more. "go test" will be
fixed and these tests will be re-enabled. They're noisy for now.
Fixes#284.
R=rsc
CC=golang-dev
https://golang.org/cl/5598049
- use proper Win64 gcc calling convention when
calling initcgo on amd64
- increase g0 stack size to 64K on amd64 to make
it the same as 386
- implement C.sleep
- do not use C.stat, since it is renamed to C._stat by mingw
- use fopen to implement TestErrno, since C.strtol
always succeeds on windows
- skip TestSetEnv on windows, because os.Setenv
sets windows process environment, while C.getenv
inspects internal C runtime variable instead
R=golang-dev, vcc.163, rsc
CC=golang-dev
https://golang.org/cl/5500094
This change doesn't pay attention to structs
so they still cannot be exported, see Issue 2552.
Fixes#2462.
R=dvyukov, rsc, iant
CC=golang-dev
https://golang.org/cl/5487058
Fixes crash when cgo consumes more than 8K
of stack and makes a callback.
Fixes#1328.
R=golang-dev, rogpeppe, rsc
CC=golang-dev, mpimenov
https://golang.org/cl/5371042
There may be more fine-tuning down the line,
but this CL fixes the most pressing issue at
hand.
Also: gofmt -w src misc
Fixes#1524.
R=rsc, bradfitz
CC=golang-dev
https://golang.org/cl/4975053
Allocate Defer on stack during cgo calls, as suggested
by dvyukov. Also includes some comment corrections.
benchmark old,ns/op new,ns/op
BenchmarkCgoCall 669 330
(Intel Xeon CPU 1.80GHz * 4, Linux 386)
R=dvyukov, rsc
CC=golang-dev
https://golang.org/cl/4910041
When the C API being used includes multiple names for the same
underlying symbol (e.g. multiple #define's for the same variable), then
cgo will generate the same placeholder variables for each name. This
then prevents the code from compiling due to multiple declarations of
the same variable - so change cgo to only create one instance of the
variable for the underlying symbol.
R=rsc
CC=golang-dev
https://golang.org/cl/4826055
The new gotest ignores Test functions outside *_test.go files
(the old shell script allowed them), so replace one clumsy hack
with another.
The root problem is that the package makefiles only know
how to run cgo for source files in the package proper, not
for test files. Making it work for test files is probably more
trouble than it's worth.
R=bradfitz
CC=golang-dev
https://golang.org/cl/4452060
* Change use of m->g0 stack (aka scheduler stack).
* Provide runtime.mcall(f) to invoke f() on m->g0 stack.
* Replace scheduler loop entry with runtime.mcall(schedule).
Runtime.mcall eliminates the need for fake scheduler states that
exist just to run a bit of code on the m->g0 stack
(Grecovery, Gstackalloc).
The elimination of the scheduler as a loop that stops and
starts using gosave and gogo fixes a bad interaction with the
way cgo uses the m->g0 stack. Cgo runs external (gcc-compiled)
C functions on that stack, and then when calling back into Go,
it sets m->g0->sched.sp below the added call frames, so that
other uses of m->g0's stack will not interfere with those frames.
Unfortunately, gogo (longjmp) back to the scheduler loop at
this point would end up running scheduler with the lower
sp, which no longer points at a valid stack frame for
a call to scheduler. If scheduler then wrote any function call
arguments or local variables to where it expected the stack
frame to be, it would overwrite other data on the stack.
I realized this possibility while debugging a problem with
calling complex Go code in a Go -> C -> Go cgo callback.
This wasn't the bug I was looking for, it turns out, but I believe
it is a real bug nonetheless. Switching to runtime.mcall, which
only adds new frames to the stack and never jumps into
functions running in existing ones, fixes this bug.
* Move cgo-related code out of proc.c into cgocall.c.
* Add very large comment describing cgo call sequences.
* Simpilify, regularize cgo function implementations and names.
* Add test suite as misc/cgo/test.
Now the Go -> C path calls cgocall, which calls asmcgocall,
and the C -> Go path calls cgocallback, which calls cgocallbackg.
The shuffling, which affects mainly the callback case, moves
most of the callback implementation to cgocallback running
on the m->curg stack (not the m->g0 scheduler stack) and
only while accounted for with $GOMAXPROCS (between calls
to exitsyscall and entersyscall).
The previous callback code did not block in startcgocallback's
approximation to exitsyscall, so if, say, the garbage collector
were running, it would still barge in and start doing things
like call malloc. Similarly endcgocallback's approximation of
entersyscall did not call matchmg to kick off new OS threads
when necessary, which caused the bug in issue 1560.
Fixes#1560.
R=iant
CC=golang-dev
https://golang.org/cl/4253054
