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>
Before, the Android exec wrapper expected the trailing exit code
output on its own line, like this:
PASS
exitcode=0
However, some tests can sometimes squeeze in some output after
the test harness outputs "PASS" and the newline. The
TestWriteHeapDumpFinalizers test is particularly prone to this,
since its finalizers println to standard out. When it happens, the
output looks like this:
PASS
finalizedexitcode=0
Two recent failures caused by this race:
https://build.golang.org/log/185605e1b936142c22350eef22d20e982be53c29https://build.golang.org/log/e61cf6a050551d10360bd90be3c5f58c3eb07605
Since the "exitcode=" string is always echoed after the test output,
the fix is simple: instead of looking for the last newline in the
output, look for the last exitcode string instead.
Change-Id: Icd6e53855eeba60b982ad3108289d92549328b86
Reviewed-on: https://go-review.googlesource.com/23750
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Before GCC 7 defined __SANITIZE_THREAD__ when using TSAN,
runtime/cgo/libcgo.h could not determine reliably whether TSAN was in
use when using GCC.
Fixes#15983.
Change-Id: I5581c9f88e1cde1974c280008b2230fe5e971f44
Reviewed-on: https://go-review.googlesource.com/23833
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
We used to check time at the point of the defer statement. This change
fixes cgo to check them when the deferred function is executed.
Fixes#15921.
Change-Id: I72a10e26373cad6ad092773e9ebec4add29b9561
Reviewed-on: https://go-review.googlesource.com/23650
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Any defer in a shared object crashed when GOARCH=386. This turns out to be two
bugs:
1) Calls to morestack were not processed to be PIC safe (must have been
possible to trigger this another way too)
2) jmpdefer needs to rewind the return address of the deferred function past
the instructions that load the GOT pointer into BX, not just past the call
Bug 2) requires re-introducing the a way for .s files to know when they are
being compiled for dynamic linking but I've tried to do that in as minimal
a way as possible.
Fixes#15916
Change-Id: Ia0d09b69ec272a176934176b8eaef5f3bfcacf04
Reviewed-on: https://go-review.googlesource.com/23623
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test for #9400 relies on an assembler function that manipulates
the stack pointer. Meanwile, it uses a global variable for
synchronization. However, position independent code on 386 use a
function call to fetch the base address for global variables.
That function call in turn overwrites the Go stack.
Fix that by fetching the global variable address once before the
stack register manipulation.
Fixes the android/386 builder.
Change-Id: Ib77bd80affaa12f09d582d09d8b84a73bd021b60
Reviewed-on: https://go-review.googlesource.com/23683
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When a wrapper method calls the real implementation, it's not possible to use a
tail call when dynamic linking on ppc64le. The bad scenario is when a local
call is made to the wrapper: the wrapper will call the implementation, which
might be in a different module and so set the TOC to the appropriate value for
that module. But if it returns directly to the wrapper's caller, nothing will
reset it to the correct value for that function.
Change-Id: Icebf24c9a2a0a9a7c2bce6bd6f1358657284fb10
Reviewed-on: https://go-review.googlesource.com/23468
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Some tests cannot build for Android; use build tags and stubs to
skip them.
For #15919
Change-Id: Ieedcb73d4cabe23c3775cfb1d44c1276982dccd9
Reviewed-on: https://go-review.googlesource.com/23634
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
The cgo tool generates compiler errors to find out what kind of name it
is using. Turning on optimization can confuse that process by producing
new unexpected messages.
Fixes#14669.
Change-Id: Idc8e35fd259711ecc9638566b691c11d17140325
Reviewed-on: https://go-review.googlesource.com/23231
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
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>
Buildmode c-archive now supports position independent code for
darwin/arm (in addition to darwin/arm64). Make PIC (-shared) the
default for both platforms in the default buildmode.
Without this change, gomobile will go install the standard library
into its separate package directory without PIC support.
Also add -shared to darwin/arm64 in buildmode c-archive, for
symmetry (darwin/arm64 always generates position independent code).
Fixes#15519
Change-Id: If27d2cbea8f40982e14df25da2703cbba572b5c6
Reviewed-on: https://go-review.googlesource.com/22920
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The old code assumed that the thread ID set by pthread_create would be
available in the newly created thread. While that is clearly true
eventually, it is not necessarily true immediately. Rather than try to
pass down the thread ID, just call pthread_self in the created thread.
Fixes#15576 (I hope).
Change-Id: Ic07086b00e4fd5676c04719a299c583320da64a1
Reviewed-on: https://go-review.googlesource.com/22880
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now that darwin/arm supports position independent code, allow the
binaries generated by the c-archive tests be position independent
(PIE) as well.
Change-Id: If0517f06e92349ada29a4e3e0a951f08b0fcc710
Reviewed-on: https://go-review.googlesource.com/22841
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#14544
Change-Id: I58b0b164ebbfeafe4ab32039a063df53e3018a6d
Reviewed-on: https://go-review.googlesource.com/22730
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Sean Lake <odysseus9672@gmail.com>
Consider three shared libraries:
libBase.so -- defines a type T
lib2.so -- references type T
lib3.so -- also references type T, and something from lib2
lib2.so will contain a type symbol for T in its symbol table, but no
definition. If, when linking lib3.so the linker reads the symbols from lib2.so
before libBase.so, the linker didn't read the type data and later crashed.
The fix is trivial but the test change is a bit messy because the order the
linker reads the shared libraries in ends up depending on the order of the
import statements in the file so I had to rename one of the test packages so
that gofmt doesn't fix the test by accident...
Fixes#15516
Change-Id: I124b058f782c900a3a54c15ed66a0d91d0cde5ce
Reviewed-on: https://go-review.googlesource.com/22744
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>
After CL 22461, c-archive build on darwin/arm is by default compiled
with -shared and installed in pkg/darwin_arm_shared.
Fix build (2nd time...)
Change-Id: Ia2bb09bb6e1ebc9bc74f7570dd80c81d05eaf744
Reviewed-on: https://go-review.googlesource.com/22534
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
After CL 22461, c-archive build on darwin/arm is by default compiled
with -shared, so update the install path.
Fix build.
Change-Id: Ie93dbd226ed416b834da0234210f4b98bc0e3606
Reviewed-on: https://go-review.googlesource.com/22507
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The GNU linker follows the letter of -znocopyreloc by refusing to
generate COPY relocations on arm64. Unfortunately it generates an
error instead of finding another way. The gold linker works, so
switch to it.
Fixes linux/arm64 build.
Change-Id: I1f7119d999c8f9f1f2d0c1e06b6462cea9c02a71
Reviewed-on: https://go-review.googlesource.com/22185
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
https://golang.org/cl/10173 intrduced msigsave, ensureSigM and
_SigUnblock but didn't enable the new signal save/restore mechanism for
SIG{HUP,INT,QUIT,ABRT,TERM} on DragonFly BSD, FreeBSD and OpenBSD.
At present, it looks like they have the implementation. This change
enables the new mechanism on DragonFly BSD, FreeBSD and OpenBSD the same
as Darwin, NetBSD.
Change-Id: Ifb4b4743b3b4f50bfcdc7cf1fe1b59c377fa2a41
Reviewed-on: https://go-review.googlesource.com/18657
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts commit ab4c9298b8.
Sysmon critically depends on system timer resolution for retaking
of Ps blocked in system calls. See #14790 for an example
of a program where execution time goes from 2ms to 30ms if
timeBeginPeriod(1) is not used.
We can remove timeBeginPeriod(1) when we support UMS (#7876).
Update #14790
Change-Id: I362b56154359b2c52d47f9f2468fe012b481cf6d
Reviewed-on: https://go-review.googlesource.com/20834
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Add supporting code for runtime initialization, including both
32- and 64-bit x86 architectures.
Add .ctors section on Windows to PE .o files, and INITENTRY to .ctors
section to plug in to the GCC C/C++ startup initialization mechanism.
This allows the Go runtime to initialize itself. Add .text section
symbol for .ctor relocations. Note: This is unlikely to be useful for
MSVC-based toolchains.
Fixes#13494
Change-Id: I4286a96f70e5f5228acae88eef46e2bed95813f3
Reviewed-on: https://go-review.googlesource.com/18057
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Change-Id: I91873aaebf79bdf1c00d38aacc1a1fb8d79656a7
Reviewed-on: https://go-review.googlesource.com/21433
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Try to avoid a race condition in the test. Passed 500 times on my
laptop.
Fixes#14956.
Change-Id: I5de2e1e3623832f0ab4f180149f7c57ce7cd23c0
Reviewed-on: https://go-review.googlesource.com/21171
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is in support of https://golang.org/cl/18057 which adds
support for c-archive to the Windows platform.
The signal handling tests do not compile on Windows. This splits
them out into a separate main_unix.c file, and conditionally
includes them for non-Windows platforms.
Change-Id: Ic79ce83da7656d6703505e514554748a482b81a1
Reviewed-on: https://go-review.googlesource.com/21086
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The exec wrapper lock file was opened, locked and then never used
again, assuming it would close and unlock at process exit.
However, the garbage collector could collect and run the *os.File
finalizer that closes the file prematurely, rendering the lock
ineffective.
Make the lock global so that the lock is live during the entire
execution.
(Hopefully) fix the iOS builders.
Change-Id: I62429e92042a0a49c4f1ea553fdb32b6ea53a43e
Reviewed-on: https://go-review.googlesource.com/21137
Reviewed-by: David Crawshaw <crawshaw@golang.org>
I failed to rebase (and re-test) CL 21102 before submit, which meant
that two extra tests sneaked into testcarchive that still referenced
runtime.GOOS and runtime.GOARCH.
Convert the new tests.
While we're here, make sure pending tasks are flushed before running
the host tests. If not, the "##### misc/cgo/testcarchive" banner
and "PASS" won't show up in the all.bash output.
Change-Id: I41fc4ec9515f9a193fa052f7c31fac452153c897
Reviewed-on: https://go-review.googlesource.com/21106
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The c-archive test were recently converted from shell script to Go.
Unfortunately, it also lost the ability to target iOS and Android
that lack C compilers and require exec wrappers.
Compile the c-archive test for the host and run it with the target
GOOS/GOARCH environment. Change the test to rely on go env GOOS
and go env GOARCH instead of runtime.GOOS and runtime.GOARCH.
Fixes#8345
Change-Id: I290ace2f7e96b87c55d99492feb7d660140dcb32
Reviewed-on: https://go-review.googlesource.com/21102
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current runtime attempts to forward signals generated by non-Go
code to the original signal handler. If it can't call the original
handler directly, it currently attempts to re-raise the signal after
resetting the handler. In this case, the original context is lost.
This fix prevents that problem by simply returning from the go signal
handler after resetting the original handler. It only does this when
the original handler is the system default handler, which in all cases
is known to not recover. The signal is not reset, so it is retriggered
and the original handler takes over with the proper context.
Fixes#14899
Change-Id: Ib1c19dfa4b50d9732d7a453de3784c8141e1cbb3
Reviewed-on: https://go-review.googlesource.com/21006
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The iOS exec wrapper use complicated machinery to run a iOS binary
on a device.
Running several binaries concurrently doesn't work (reliably), which
can break tests running concurrently. For my setup, the
runtime:cpu124 and sync_cpu tests can't run reliably without one of them
crashing.
Add a file lock to the exec wrapper to serialize execution.
Fixes#14318 (for me)
Change-Id: I023610e014b327f8d66f1d2fd2e54dd0e56f2be0
Reviewed-on: https://go-review.googlesource.com/21074
Reviewed-by: David Crawshaw <crawshaw@golang.org>
A retry mechanism is in place to combat the inherent flakiness of
launching iOS test binaries. Before it covered just the starting of
lldb; expand it to cover the setup steps as well. Note that the
running of the binary itself is (still) not retried, to avoid
covering over genuine bugs.
On my test device (iPhone 5S, iOS 9.3) starting lldb can take longer
than 10 seconds, so increase the timeout for that.
Furthermore, some basic steps such as setting breakpoints in lldb
can take longer than the 1 second timeout. Increase that timeout
as well, to 2 seconds.
Finally, improve the error message for when ios-deploy is not
installed.
For #14318
Change-Id: Iba41d1bd9d023575b9454cb577b08f8cae081c2a
Reviewed-on: https://go-review.googlesource.com/21072
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Instruct lldb to pass through SIGCONT unhindered when running iOS
tests. Fixes the TestSIGCONT test in os/signal.
For #14318
Change-Id: I669264208cc3d6ecae9fbc8790e0b753a93a5e04
Reviewed-on: https://go-review.googlesource.com/21071
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is to support https://golang.org/cl/18057, which is going to add
Windows support to this directory. Better to write the test in Go then
to have both test.bash and test.bat.
Update #13494.
Change-Id: I4af7004416309e885049ee60b9470926282f210d
Reviewed-on: https://go-review.googlesource.com/20892
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When building shared libraries, all symbols on Allsym are marked reachable.
What I didn't realize was that this includes the ".dup" symbols created when
"dupok" symbols are read from multiple package files. This breaks now because
deadcode makes some assumptions that fail for these ".dup" symbols, but in any
case was a bad idea -- I suspect this change makes libstd.so a bunch smaller,
but creating it was broken before this CL so I can't be sure.
This change simply stops adding these symbols to Allsym, which might make some
of the many iterations over Allsym the linker does a touch quicker, although
that's not the motivation here.
Add a test that no symbols called ".dup" makes it into the runtime shared
library.
Fixes#14841
Change-Id: I65dd6e88d150a770db2d01b75cfe5db5fd4f8d25
Reviewed-on: https://go-review.googlesource.com/20780
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: 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>
cmd/link is clearly the way forward.
The original rationale for cmd/newlink was that it would be a clean Go reimplementation.
But when push came to shove, cmd/link got converted from C instead,
and all the work on build modes and the like is in cmd/link now.
Cleaning up cmd/link is likely a much better plan.
This directory is something to delete from releases and the
testdata is something that breaks every time the .6 format changes.
Fix both problems by just deleting it outright.
Change-Id: Ib00fecda258ba685f1752725971182af9d4459eb
Reviewed-on: https://go-review.googlesource.com/20380
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Latest version of gcc (tdm-1) 5.1.0 refuses to compile our code
on windows/386 (see issue for details). Rewrite the code.
Fixes#14328
Change-Id: I70f4f063282bd2958cd2175f3974369dd49dd8dc
Reviewed-on: https://go-review.googlesource.com/20008
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@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>
Single quotes to not expand variables inside of them.
Change-Id: I4a0622c0aebfc1c3f9d299f93f7a8253893b5858
Reviewed-on: https://go-review.googlesource.com/13661
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Looks like this was intended to match a literal period to restrict
this to `.go` files, but in POSIX grep, the unescaped period matches
any character.
Change-Id: I20e00323baa9e9631792eff5035966297665bbee
Reviewed-on: https://go-review.googlesource.com/19880
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds support for Fortran files (.f, .F, .for, .f90) to the
go tool, in a similar fashion to Objective-C/C++. Only gfortran is
supported out of the box so far but leaves other Fortran compiler
toolchains the ability to pass the correct link options via CGO_LDFLAGS.
A simple test (misc/cgo/fortran) has been added and plugged into the
general test infrastructure. This test is only enabled when the $FC
environment variable is defined (or if 'gfortran' was found in $PATH.)
Derived from CL 4114.
Change-Id: Ifc855091942f95c6e9b17d91c17ceb4eee376408
Reviewed-on: https://go-review.googlesource.com/19670
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
And update two imports in cmd/internal/objfile/disasm.go.
This makes GO15VENDOREXPERIMENT=0 ./make.bash work.
For Go 1.7 we will move it back.
Fixes#14236.
Change-Id: I429c9af4baff8496f83d113b1b03b90e309f4f48
Reviewed-on: https://go-review.googlesource.com/19384
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It's awkward to get a string value in cgoCheckArg, but SWIG testing
revealed that it is possible. The new handling of extra files in the
ptr.go test emulates what SWIG does with an exported function that
returns a string.
Change-Id: I453717f867b8a49499576c28550e7c93053a0cf8
Reviewed-on: https://go-review.googlesource.com/19020
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@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>
People who want to use -buildmode=c-archive in unusual cross-compilation
setups will need something like this. It could also be done via (yet
another) environment variable but I use -extar by analogy with the
existing -extld.
Change-Id: I354cfabc4c470603affd13cd946997b3a24c0e6c
Reviewed-on: https://go-review.googlesource.com/18913
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@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>
https://golang.org/s/execmodes defines rules for how multiple codes of a go
package work when they end up in the address space of a single process, but
currently the linker blows up in this situation. Fix that by loading all .a
files before any .so files and ignoring duplicate symbols found when loading
shared libraries.
I know this is very very late for 1.6 but at least it should clearly not have
any effect when shared libraries are not in use.
Change-Id: I512ac912937e7502ff58eb5628b658ecce3c38e5
Reviewed-on: https://go-review.googlesource.com/18714
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
* Enable c-shared buildmode on darwin/386
* dyld does not support text relocation on i386. Add -read_only_relocs suppress flag to linker
Fixes#13904
Change-Id: I9adbd20d3f36ce9bbccf1bffb746b391780d088f
Reviewed-on: https://go-review.googlesource.com/18500
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Russ Cox <rsc@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>
The previous behaviour of installing the signal handlers in a separate
thread meant that Go initialization raced with non-Go initialization if
the non-Go initialization also wanted to install signal handlers. Make
installing signal handlers synchronous so that the process-wide behavior
is predictable.
Update #9896.
Change-Id: Ice24299877ec46f8518b072a381932d273096a32
Reviewed-on: https://go-review.googlesource.com/18150
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It's fairly common to call cgo functions with conversions to
unsafe.Pointer or other C types. Apply the simpler checking of address
expressions when possible when the address expression occurs within a
type conversion.
Change-Id: I5187d4eb4d27a6542621c396cad9ee4b8647d1cd
Reviewed-on: https://go-review.googlesource.com/18391
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
After a failure on the build dashboard I tested testcarchive test 2 and
found that it failed an average of 1 in 475 runs on my laptop. With
this change it ran over 50,000 times without failing. I bumped up the
other iteration limits to correspond.
Change-Id: I0155c68161a2c2a09ae25c91e9269f1e8702628d
Reviewed-on: https://go-review.googlesource.com/18309
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When calling a Go function on a C thread, if the C thread already has an
alternate signal stack, use that signal stack instead of installing a
new one.
Update #9896.
Change-Id: I62aa3a6a4a1dc4040fca050757299c8e6736987c
Reviewed-on: https://go-review.googlesource.com/18108
Reviewed-by: Russ Cox <rsc@golang.org>
Avoids an msan error when runtime/cgo is explicitly rebuilt with
-fsanitize=memory.
Fixes#13815.
Change-Id: I70308034011fb308b63585bcd40b0d1e62ec93ef
Reviewed-on: https://go-review.googlesource.com/18263
Reviewed-by: Russ Cox <rsc@golang.org>
Following the parallelization of some tests, a race condition can
occur in testcarchive, testshared and testcshared.
In some cases, it can result in the go env GOROOT command returning
corrupted data, which are then passed to a rm command.
Make the shell script more robust by not trusting the result of
the go env GOROOT command. It does not really fix the issue, but
at least prevent the entire repository to be deleted.
Updates #13789
Change-Id: Iaf04a7bd078ed3a82e724e35c4b86e6f756f2a2f
Reviewed-on: https://go-review.googlesource.com/18173
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 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>
Only install signal handlers for synchronous signals that become
run-time panics. Set the SA_ONSTACK flag for other signal handlers as
needed.
Fixes#13028.
Update #12465.
Update #13034.
Update #13042.
Change-Id: I28375e70641f60630e10f3c86e24b6e4f8a35cc9
Reviewed-on: https://go-review.googlesource.com/17903
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This file is not part of the benchmark shootout, and we wrote it, so use
the usual copyright header, not a partial version of the shootout
license.
Fixes#13575.
Change-Id: Ib610e2ad82914b4ef096a2424cfffe3383db2d5b
Reviewed-on: https://go-review.googlesource.com/17715
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The build tags are necessary to keep "go build" in that directory
building only stdio.go, but we have to arrange for test/run.go to
treat them as satisfied.
Fixes#12625.
Change-Id: Iec0cb2fdc2c9b24a4e0530be25e940aa0cc9552e
Reviewed-on: https://go-review.googlesource.com/17454
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There is a report that fd 10 is already in use when run on some OS X machines.
I don't see how, and I can't reproduce the problem on my own OS X machine,
but it's easy enough to fix.
Fixes#12161.
Change-Id: I73511bdd91258ecda181d60d2829add746d1198b
Reviewed-on: https://go-review.googlesource.com/17451
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fix a typo in de5b386; using `$ver` to determine linux major/minor
versions would produce those for clang, use `$linuxver` instead.
Updates #12898.
Change-Id: I2c8e84ad02749fceaa958afd65e558bb0b08dddb
Reviewed-on: https://go-review.googlesource.com/17323
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
These are simply incompatible. Clang fixed the bug but not in older versions.
Fixes#12898.
Change-Id: I74a3fd9134dadab6d0f074f8fd09e00d64558d7a
Reviewed-on: https://go-review.googlesource.com/17254
Reviewed-by: Ian Lance Taylor <iant@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>
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>
Without the fix:
$ CC=clang-3.5 ./test.bash
misc/cgo/errors/test.bash: BUG: expected error output to contain "C.ushort" but saw:
# command-line-arguments
./issue13129.go:13: cannot use int(0) (type int) as type C.unsignedshort in assignment
Fixes#13129.
Change-Id: I2c019d2d000f5bfa3e33c477e533aff97031a84f
Reviewed-on: https://go-review.googlesource.com/17207
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Found by cmd/vet
Change-Id: I29dd207ecd40fe703054e8ad4e81b3267ca89da2
Reviewed-on: https://go-review.googlesource.com/17160
Reviewed-by: David Crawshaw <crawshaw@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>
If you set GODEBUG=cgocheck=2 the runtime package will use the write
barrier to detect cases where a Go program writes a Go pointer into
non-Go memory. In conjunction with the existing cgo checks, and the
not-yet-implemented cgo check for exported functions, this should
reliably detect all cases (that do not import the unsafe package) in
which a Go pointer is incorrectly shared with C code. This check is
optional because it turns on the write barrier at all times, which is
known to be expensive.
Update #12416.
Change-Id: I549d8b2956daa76eac853928e9280e615d6365f4
Reviewed-on: https://go-review.googlesource.com/16899
Reviewed-by: Russ Cox <rsc@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>
I keep losing this utility, used as part of other tools to auto-update
the AUTHORS and CONTRIBUTORS files. Check it in to the repo so I
don't lose it, and so others can use it as well.
Updates #12042
Change-Id: Ib5886b85799087aaaddcec4c81169e2726322c05
Reviewed-on: https://go-review.googlesource.com/16824
Reviewed-by: Russ Cox <rsc@golang.org>
The runtime is not instrumented, but the calls to msanread in the
runtime can sometimes refer to the system stack. An example is the call
to copy in stkbucket in mprof.go. Depending on what C code has done,
the system stack may appear uninitialized to msan.
Change-Id: Ic21705b9ac504ae5cf7601a59189302f072e7db1
Reviewed-on: https://go-review.googlesource.com/16660
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is a fix for the -msan option when using cgo callbacks. A cgo
callback works by writing out C code that puts a struct on the stack and
passes the address of that struct into Go. The result parameters are
fields of the struct. The Go code will write to the result parameters,
but the Go code thinks it is just writing into the Go stack, and
therefore won't call msanwrite. This CL adds a call to msanwrite in the
cgo callback code so that the C knows that results were written.
Change-Id: I80438dbd4561502bdee97fad3f02893a06880ee1
Reviewed-on: https://go-review.googlesource.com/16611
Reviewed-by: David Crawshaw <crawshaw@golang.org>
