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>
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>
And enable PIE in cmd/go because that's all it seems to take.
Change-Id: Ie017f427ace5e91de333a9f7cba9684c4641dfd5
Reviewed-on: https://go-review.googlesource.com/14222
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current mechanism fails if clang cannot be executed by the current
user. Using the `-x` operator for `test` return TRUE if the file is
executable by the user.
Change-Id: I0f3c8dc3880c1ce5a8a833ff3109eb96853184af
Reviewed-on: https://go-review.googlesource.com/16752
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing go_darwin_arm_exec.go script does not work with Xcode 7,
not due to any significant changes, but just ordering and timing of
statements from lldb. Unfortunately the current design of
go_darwin_arm_exec.go makes it not obvious what gets stuck where, so
this moves from a moving buffer window to a complete buffer of the
lldb output.
The result is easier code to follow, and it works with Xcode 7.
Updates #12660.
Change-Id: I3b8b890b0bf4474119482e95d84e821a86d1eaed
Reviewed-on: https://go-review.googlesource.com/16634
Reviewed-by: Michael Matloob <matloob@golang.org>
The width of the type of an external variable defined with a type
literal may not be set when the instrumentation pass is run. There are
two cases in the standard library that fail without the call to dowidth:
../../../src/encoding/base32/base32.go:322: constant -1000000000 overflows uintptr
../../../src/encoding/base32/base32.go:329: constant -1000000000 overflows uintptr
../../../src/encoding/json/encode.go:385: constant -1000000000 overflows uintptr
../../../src/encoding/json/encode.go:387: constant -1000000000 overflows uintptr
Change-Id: I7c3334f7decdb7488595ffe4090cd262d7334283
Reviewed-on: https://go-review.googlesource.com/16331
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
On older versions of GCC we need to pass a file name before GCC will
report an unrecognized option.
Fixes#13065.
Change-Id: I7ed34c01a006966a446059025f7d10235c649072
Reviewed-on: https://go-review.googlesource.com/16589
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The error message should indicate the name of the unset variable,
rather than the value. The value will alwayse be empty.
Change-Id: I6f6c165074dfce857b6523703a890d205423cd28
Reviewed-on: https://go-review.googlesource.com/16555
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Depends on external linking right now. I have no immediate use for
this, but wanted to check how hard it is to support as android/amd64
is coming and it will require PIE.
Change-Id: I65c6b19159f40db4c79cf312cd0368c2b2527bfd
Reviewed-on: https://go-review.googlesource.com/16072
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also fix the msan_fail test. It was bogus, since it always aborted one
way or another.
Change-Id: Ic693327d1bddb7bc5c7d859ac047fc93cb9b5b1c
Reviewed-on: https://go-review.googlesource.com/16172
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The -msan option compiles Go code to use the memory sanitizer. This is
intended for use when linking with C/C++ code compiled with
-fsanitize=memory. When memory blocks are passed back and forth between
C/C++ and Go, code in both languages will agree as to whether the memory
is correctly initialized or not, and will report errors for any use of
uninitialized memory.
Change-Id: I2dbdbd26951eacb7d84063cfc7297f88ffadd70c
Reviewed-on: https://go-review.googlesource.com/16169
Reviewed-by: David Crawshaw <crawshaw@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>
Also, handle the case where 'read' returns EINVAL instead of EBADF
when the descriptor is not ready. (android 4.4.4/cyanogenmod, nexus7)
Change-Id: I56c5949d27303d44a4fd0de38951b85e20cef167
Reviewed-on: https://go-review.googlesource.com/15810
Reviewed-by: Ian Lance Taylor <iant@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>
cgo panics in Package.rewriteRef for:
var a = C.enum_test(1)
or
p := new(C.enum_test)
when the corresponding enum type is not defined.
Check nil values for Type fields and issue a proper
error instead.
Fixes#11097
Updates #12160
Change-Id: I5821d29097ef0a36076ec5273125b09846c7d832
Reviewed-on: https://go-review.googlesource.com/15264
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The memory sanitizer (msan) is a nice compiler feature that can
dynamically check for memory errors in C code. It's not useful for Go
code, since Go is memory safe. But it is useful to be able to use the
memory sanitizer on C code that is linked into a Go program via cgo.
Without this change it does not work, as msan considers memory passed
from Go to C as uninitialized.
To make this work, change the runtime to call the C mmap function when
using cgo. When using msan the mmap call will be intercepted and marked
as returning initialized memory.
Work around what appears to be an msan bug by calling malloc before we
call mmap.
Change-Id: I8ab7286d7595ae84782f68a98bef6d3688b946f9
Reviewed-on: https://go-review.googlesource.com/15170
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Currently Go produces shared libraries that cannot be shared between processes
because they have relocations against the text segment (not text section). This
fixes this by moving some data to sections with magic names recognized by the
static linker.
The change in genasmsym to add STYPELINK to the switch should fix things on
darwin/arm64.
Fixes#10914
Updates #9210
Change-Id: Iab4a6678dd04cec6114e683caac5cf31b1063309
Reviewed-on: https://go-review.googlesource.com/14306
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts commit 2c2cbb69c8.
Broke darwin/arm64
Change-Id: Ibd2dea475d6ce6a8b4b40e2da19a83fc0514025d
Reviewed-on: https://go-review.googlesource.com/14301
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently Go produces shared libraries that cannot be shared between processes
because they have relocations against the text segment (not text section). This
fixes this by moving some data to sections with magic names recognized by the
static linker.
Fixes#10914
Updates #9210
Change-Id: I7178daadc0ae87953d5a084aa3d580f4e3b46d47
Reviewed-on: https://go-review.googlesource.com/10300
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#12083
Change-Id: I8256739b33cf08d84dec23120d527667de2e6eea
Reviewed-on: https://go-review.googlesource.com/13822
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@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>
This is now superseded by golang.org/x/build/cmd/release.
Fixes#8472
Change-Id: I59664d84996a0fbb5c90582a4702714b3b3cf302
Reviewed-on: https://go-review.googlesource.com/12500
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is mostly Russ's https://golang.org/cl/12145 but with some extra fixes to
account for the fact that function declarations without implementations now
break shared libraries, and including my test case.
Fixes#11480.
Change-Id: Iabdc2934a0378e5025e4e7affadb535eaef2c8f1
Reviewed-on: https://go-review.googlesource.com/12340
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
Integrate the latest trace-viewer changes.
It now handles nanoseconds without any issues (thanks to @egonelbre!).
So change timestamps from microseconds to nanoseconds.
Change-Id: I010f27effde7e80c9992e6f276f6912354d27df4
Reviewed-on: https://go-review.googlesource.com/11244
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Egon Elbre <egonelbre@gmail.com>
Refactor main a bit to make it possible to run tests without an exec every time.
(Makes a huge difference in run time.)
Add a silver test. Not quite golden, since it looks for pieces rather than the
full output, and also includes tests for what should not appear.
Fixes#10920.
Change-Id: I6a4951cc14e61763379754a10b0cc3484d30c267
Reviewed-on: https://go-review.googlesource.com/11272
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
All of the heavy-lifting was done by minux@, with his external-linking support
for darwin/arm64: golang.org/cl/8781
Change-Id: I7c9fbc19246f418c065c92fb2c13c00026ff0f82
Reviewed-on: https://go-review.googlesource.com/11127
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Adjust timestamps in TestABIChecking to make sure that the library and
executable are rebuilt when expected.
Change-Id: I3288c254ba8201b5b4255347b0cb056fa0908657
Reviewed-on: https://go-review.googlesource.com/11128
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change reintroduces CL 8523. CL 8523 was reverted because
it broke darwin and netbsd builds. Now that this test is part
of "go tool dist test" command we could skip OSes that fail.
Updates #10360
Change-Id: Iaaeb5b800126492f36415a439c333a218fe4ab67
Reviewed-on: https://go-review.googlesource.com/11119
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This makes the behaviour match what happens when duplicate symbols are read
from regular object files and fixes errors about cgoAlwaysFalse when linking
an executable that uses cgo against a shared library.
Change-Id: Ibb8cd8fe3f7813cde504b7483f1e857868d7e063
Reviewed-on: https://go-review.googlesource.com/11117
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: Id93b8ab42fa311ce32209734ec9a0813f8736e25
Reviewed-on: https://go-review.googlesource.com/9914
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Update to tip to fix#11003 (not possible to select events in chromium).
Fixed#11003
Change-Id: Ibba5d39ca809cfd5cb79c9e6d152b00899d49e08
Reviewed-on: https://go-review.googlesource.com/11062
Reviewed-by: Andrew Gerrand <adg@golang.org>
I would like to re-apply reverted http://golang.org/cl/8523.
Reverted tests still fail in some environments (see issue #10360).
It is easier to run tests selectively when in Go.
This CL prepares for the changes.
Updates #10360
Change-Id: Iefeb1d71cb3d1cfa653a6ccd9f6e35686c0c5b24
Reviewed-on: https://go-review.googlesource.com/10608
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We already read the address of a gcmask/gcprog out of the type data, but I
didn't know how many bytes to read. But it turns out that it's easy to
calculate, so change to do that. This means that we no longer depend on the
local symbols being present, allowing me to strip the shared libraries for
distribution and make them a lot smaller.
As a bonus, this makes LSym another 24 bytes smaller, down to 296 bytes now.
Change-Id: I379d359e28d63afae6753efd23efdf1fbb716992
Reviewed-on: https://go-review.googlesource.com/10377
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The motivation for this is the innocuous looking test case that is added. This
creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem
comes from the fact that a function from libdep.so gets inlined all the way
into exe. This (unsurprisingly) means that the object file for exe references
symbols from libdep.so, which means that -ldep needs to be passed when linking
exe and it isn't. The fix is simply to pass it -- there is no harm in passing
it when it's not needed.
The thing is, it's not clear at all in the current code to see how the linker
can know that libdep2 is linked against libdep. It could look through the
DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it
feels better to be explicit. So this adds another SHT_NOTE section that lists
the shared libraries a shared library was linked against, and makes sure the
complete set of depended upon shared libraries is passed to the external
linker.
Change-Id: I79aa6f98b4db4721d657a7eb7b7f062269bf49e2
Reviewed-on: https://go-review.googlesource.com/10376
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This makes for a more stable API for tools (including cmd/link itself) to
extract the abi hash from a shared library and makes it possible at all for a
library that has had the local symbol table removed.
The existing note-writing code only supports writing notes into the very start
of the object file so they are easy to find in core dumps. This doesn't apply
to the "go" notes and means that all notes have to fit into a fixed size
budget. That's annoying now we have more notes (and the next CL will add
another one) so this does a little bit of work to make adding notes that do not
have to go at the start of the file easier and moves the writing of the package
list note over to that mechanism, which lets me revert a hack that increased
the size budget mentioned above for -buildmode=shared builds.
Change-Id: I6077a68d395c8a2bc43dec8506e73c71ef77d9b9
Reviewed-on: https://go-review.googlesource.com/10375
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I8694ee5e5642c31815ae63cd414a3b1fcd9c95b0
Reviewed-on: https://go-review.googlesource.com/10411
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@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>
In preparation for making the current linker cmd/link.
If cmd/newlink is ever completed, it can be moved back.
See golang-dev thread titled "go tool compile, etc" for background.
Change-Id: I4029580f470038240c5181a37ea4202ba971f9ef
Reviewed-on: https://go-review.googlesource.com/10286
Reviewed-by: Rob Pike <r@golang.org>
On my systems, ld -rpath sets DT_RUNPATH instead of DT_RPATH.
Change-Id: I5047e795fb7ef9336f5fa13ba24bb6245c0b0582
Reviewed-on: https://go-review.googlesource.com/10260
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
And fix to work on filesystems with only 1s resolution.
Fixes#10724
Change-Id: Ia07463f090b4290fc27f5953fa94186463d7afc7
Reviewed-on: https://go-review.googlesource.com/9768
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
'env' command is not available on some android devices.
Change-Id: I68b1152ef7ea248c8e80c7f71e97da76e3ec6394
Reviewed-on: https://go-review.googlesource.com/9999
Reviewed-by: Minux Ma <minux@golang.org>
On android the generated header files are located in
pkg/$(go env GOOS)_$(go env GOARCH)_testcshared.
The test was broken since https://go-review.googlesource.com/9798.
The installation path differs based on codegenArgs
(around src/cmd/go/build.go line 389), and the codegenArgs
is platform dependent.
Change-Id: I01ae9cb957fb7676e399f3b8c067f24c5bd20b9d
Reviewed-on: https://go-review.googlesource.com/9980
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This:
1) Defines the ABI hash of a package (as the SHA1 of the __.PKGDEF)
2) Defines the ABI hash of a shared library (sort the packages by import
path, concatenate the hashes of the packages and SHA1 that)
3) When building a shared library, compute the above value and define a
global symbol that points to a go string that has the hash as its value.
4) When linking against a shared library, read the abi hash from the
library and put both the value seen at link time and a reference
to the global symbol into the moduledata.
5) During runtime initialization, check that the hash seen at link time
still matches the hash the global symbol points to.
Change-Id: Iaa54c783790e6dde3057a2feadc35473d49614a5
Reviewed-on: https://go-review.googlesource.com/8773
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
addmoduledata is called from a .init_array function and need to follow the
platform ABI. It contains accesses to global data which are rewritten to use
R15 by the assembler, and as R15 is callee-save we need to save it.
Change-Id: I03893efb1576aed4f102f2465421f256f3bb0f30
Reviewed-on: https://go-review.googlesource.com/9941
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The trace-viewer doesn't use the Go license, so it makes sense
to include the license text into the README.md file.
While we're at here, reformat existing text using real Markdown
syntax.
Change-Id: I13e42d3cc6a0ca7e64e3d46ad460dc0460f7ed09
Reviewed-on: https://go-review.googlesource.com/9882
Reviewed-by: Rob Pike <r@golang.org>
When
using -buildmode=c-archive or c-shared, and
when installing packages that use cgo, and
when those packages export some functions via //export comments,
then
for each such package, install a pkg.h header file that declares the
functions.
This permits C code to #include the header when calling the Go
functions.
This is a little awkward to use when there are multiple packages that
export functions, as you have to "go install" your c-archive/c-shared
object and then pull it out of the package directory. When compiling
your C code you have to -I pkg/$GOOS_$GOARCH. I haven't thought of
any more convenient approach. It's simpler when only the main package
has exported functions.
When using c-shared you currently have to use a _shared suffix in the
-I option; it would be nice to fix that somehow.
Change-Id: I5d8cf08914b7d3c2b194120c77791d2732ffd26e
Reviewed-on: https://go-review.googlesource.com/9798
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This changes the action graph when shared libraries are involved to always have
an action for the shared library (which does nothing when the shared library
is up to date).
Change-Id: Ibbc70fd01cbb3f4e8c0ef96e62a151002d446144
Reviewed-on: https://go-review.googlesource.com/8934
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix several warnings generated on the linux-amd64-clang builder
and make it clear to clang that -znow is a linker only flag.
Tested with
env CC=clang-3.5 ./all.bash
env CC=gcc-4.8 ./all.bash
Change-Id: I5ca7366ba8bf6221a36d25a2157dda4b4f3e16fa
Reviewed-on: https://go-review.googlesource.com/9523
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Just a first basic test, I'll extend this to test more but want to get an
opinion on basic approach first.
Change-Id: Idab9ebd7d9960b000b81a01a1e53258bf4bce755
Reviewed-on: https://go-review.googlesource.com/9386
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: 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>
Instead of comparing against the entire output that may include
verbose warning messages, use the last line of the output and check
it includes the expected success message (PASS).
Change-Id: Iafd583ee5529a8aef5439b9f1f6ce0185e4b1331
Reviewed-on: https://go-review.googlesource.com/9304
Reviewed-by: David Crawshaw <crawshaw@golang.org>
- main3.c tests main.main is exported when compiled for GOOS=android.
- wait longer for main2.c (it's slow on android/arm)
- rearranged test.bash
Fixes#10070.
Change-Id: I6e5a98d1c5fae776afa54ecb5da633b59b269316
Reviewed-on: https://go-review.googlesource.com/9296
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Forward signals to signal handlers installed before Go installs its own,
under certain circumstances. In particular, as iant@ suggests, signals are
forwarded iff:
(1) a non-SIG_DFL signal handler existed before Go, and
(2) signal is synchronous (i.e., one of SIGSEGV, SIGBUS, SIGFPE), and
(3a) signal occured on a non-Go thread, or
(3b) signal occurred on a Go thread but in CGo code.
Supported only on Linux, for now.
Change-Id: I403219ee47b26cf65da819fb86cf1ec04d3e25f5
Reviewed-on: https://go-review.googlesource.com/8712
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The purpose of this test is to make sure that -buildmode=c-shared
works even when the shared library can be built without invoking cgo.
Change-Id: Id6f95af755992b209aff770440ca9819b74113ab
Reviewed-on: https://go-review.googlesource.com/9166
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Change-Id: I0d3f9841500e0a41f1c427244869bf3736a31e18
Reviewed-on: https://go-review.googlesource.com/9075
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Followed the same test pattern in misc/cgo/testcarchive.
Change-Id: I2f863b5c24a28f0b38b0128ed3e8a92c17fb5b9f
Reviewed-on: https://go-review.googlesource.com/8985
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@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>
This is a follow-up to CL 8910.
This is the version that I have tested and which works
when appID and teamID are not the same (which they appear
to be for the builder).
I am unsure how I submitted it with the wrong code.
Change-Id: I186e34e91953d082b507390c1cd2042e5419c4c9
Reviewed-on: https://go-review.googlesource.com/8943
Reviewed-by: David Crawshaw <crawshaw@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>
We no longer need the EXC_BAD_ACCESS watcher as runtime/cgo contains
a mach exception handler that catches it. And now lldb only
intermittently reports process connection and exiting, so instead
just look for the PASS from Go.
Change-Id: I403266558f5a900e0b87ec1019d9baec88148d23
Reviewed-on: https://go-review.googlesource.com/8957
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Use environment variables to allow set-and-forget.
Add a script to attempt to autodetect codesign info.
Change-Id: Ic56b9c5f097b1a4117ebb89c408bc333d91f581d
Reviewed-on: https://go-review.googlesource.com/8910
Reviewed-by: David Crawshaw <crawshaw@golang.org>
With the new buildmodes c-archive and c-shared, it is possible for a
cgo call to come in early in the lifecycle of a Go program. Calls
before the runtime has been initialized are caught by
_cgo_wait_runtime_init_done. However a call can come in after the
runtime has initialized, but before the program's package init
functions have finished running.
To avoid this cgocallback checks m.ncgo to see if we are on a thread
running Go. If not, we may be a foreign thread and it blocks until
main_init is complete.
Change-Id: I7a9f137fa2a40c322a0b93764261f9aa17fcf5b8
Reviewed-on: https://go-review.googlesource.com/8897
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
The -lldb flag makes it easy to use go run and end up in a debugging
session on darwin/arm.
Change-Id: I556f93e950086a7dff4839f301b9c55f7579f87b
Reviewed-on: https://go-review.googlesource.com/8024
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This reverts commit 9fa9f966e9.
The change has broken darwin and netbsd builders. It needs to be tested properly.
Change-Id: Id9e2d30caa8764c362c9f33890015dfc1aae0dab
Reviewed-on: https://go-review.googlesource.com/8527
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
After moving the darwin/arm builder to new hardware several new flaky
error messages appeared. This provided enough information to Google
to make it clear that iOS build systems have been flaky for many
years, and that is unlikely to change any time soon.
However, all of the pain of lldb and using a breakpoint early in
program initialization gives us an advantage: all install and
initialization flakiness appears to happen before the Go program ever
gets going. So if we see an error or we timeout before we reach our
breakpoint (before any test code has executed), we can assume it is
the fault of the builder and restart without risking hiding a flaky
Go test.
This code has successfully processed the last 8 builds. I am hopeful.
Change-Id: Ide24aaae4fa7bdab9d8f4432bb85d8f2256c7606
Reviewed-on: https://go-review.googlesource.com/8241
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The clever partial timer I added interacts badly with iOS app launch
timeout termination. A fixed timeout will be easier to debug.
Change-Id: I6eb4ee5f1431539f00fa707e8cde6f3cf86983fc
Reviewed-on: https://go-review.googlesource.com/8083
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Split out from cl/8024 for clarity and improved approach.
Rarely, "stop reason = breakpoint" does not appear in the lldb stop
text. However the program is ready to proceed. To be a little more
robust about those cases, we wait for two seconds, and if that text
doesn't appear but a prompt does we continue and hope for the best.
Worst case, this results in a harder to read failure message.
Change-Id: Ib20aa92564cdccefd2b7260417c647cd44122b66
Reviewed-on: https://go-review.googlesource.com/8080
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The SecureRandom named service was removed in
https://codereview.chromium.org/550523002. And the new syscall
was introduced in https://codereview.chromium.org/537543003.
Accepting this will remove the support for older version of
sel_ldr. I've confirmed that both pepper_40 and current
pepper_canary have this syscall.
After this change, we need sel_ldr from pepper_39 or above to
work.
Fixes#9261
Change-Id: I096973593aa302ade61f259a3a71ebc7c1a57913
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1755
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The test used to import ../callback. I forget why that ever worked,
but it probably had something to do with the shared libraries we used
to use with SWIG. It doesn't work today.
Change-Id: Ib83d6c398aa46bf2fc66320b47b6e6d9897ee0b7
Reviewed-on: https://go-review.googlesource.com/7004
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This will enable test sharding over multiple VMs, to speed trybot answers.
Update #10029
Change-Id: Ie277c6459bc38005e4d6af14d22effeaa0a4667e
Reviewed-on: https://go-review.googlesource.com/6531
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
We now wait until we see the completed prompt from a command before
proceeding. This seems to cut down on a spurious error I have seen
this afternoon.
Change-Id: Ic0a3481d8c265c3c3b4449ec7ac1c2752b85b0b6
Reviewed-on: https://go-review.googlesource.com/6691
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
See golang.org/cl/6511.
Change-Id: I2145a42877ed6b78400f29c2ef18969870dab5c3
Reviewed-on: https://go-review.googlesource.com/6512
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This script is getting very close to complete, and is complex enough
that I'd like to get what's there so far reviewed. With it the builder
is left failing on eight packages. Two of those involve correcting
GOROOT which may need modifications to this script, the others are
either a unix sockets bug I have to hunt down or are caused by lldb
getting stuck on SIGSEGV, a TODO.
Change-Id: I5ff933800167b6764b51ad195da7dcda61d59ff8
Reviewed-on: https://go-review.googlesource.com/6404
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trace command allows to visualize and analyze traces.
Run as:
$ go tool trace binary trace.file
The commands opens web browser with the main page,
which contains links for trace visualization,
blocking profiler, network IO profiler and per-goroutine
traces.
Also move trace parser from runtime/pprof/trace_parser_test.go
to internal/trace/parser.go, so that it can be shared between
tests and the command.
Change-Id: Ic97ed59ad6e4c7e1dc9eca5e979701a2b4aed7cf
Reviewed-on: https://go-review.googlesource.com/3601
Reviewed-by: Andrew Gerrand <adg@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>
This dashboard is no longer in use, and doesn't work with Gerrit.
Change-Id: Ib7c367dcad97322566610157b15e23db5bec58ff
Reviewed-on: https://go-review.googlesource.com/3028
Reviewed-by: David Symonds <dsymonds@golang.org>
This change includes the cleanup of temporary files created during
the binary execution as well.
Change-Id: Ic01a0a537d1daafcaa3acda1ec344aff5dcddfc2
Reviewed-on: https://go-review.googlesource.com/2903
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This test requires external linking, but we don't yet implement
external linking on ppc64 (tracked in issue #8912). Disable the test
on ppc64 until external linking is implemented.
This makes all.bash pass on ppc64le.
Change-Id: I741498d4d9321607e7a65792a33faf8187bd18e4
Reviewed-on: https://go-review.googlesource.com/2908
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Git marks some of its files read only, so os.RemoveAll isn't sufficient
to remove them from the ".git" directory.
Change-Id: I3150596931d1c77e7cf9fb8da1a999d2c6730121
Reviewed-on: https://go-review.googlesource.com/2930
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
SWIG has always returned a typed interface value for a C++ class,
so the interface value will never be nil even if the pointer itself
is NULL. ptr == NULL in C/C++ should be ptr.Swigcptr() == 0 in Go.
Fixes#9514.
Change-Id: I3778b91acf54d2ff22d7427fbf2b6ec9b9ce3b43
Reviewed-on: https://go-review.googlesource.com/2440
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now that there's no 6c compiler anymore, there's no need for cgo to
generate C headers that are compatible with it.
Fixes#9528
Change-Id: I43f53869719eb9a6065f1b39f66f060e604cbee0
Reviewed-on: https://go-review.googlesource.com/2482
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>
Also: checkout sub-repos from Mercurial manually
instead of using "go get". (for the 1.4 release)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/190720043
Turns out it *is* needed because the cmd/link tests expect to find their own files.
««« original CL description
misc/nacl: exclude cmd/link from the test zip.
It does not appear to be necessary, and cmd/link does not appear in release branches.
LGTM=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/176900044
»»»
TBR=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/175870045
It does not appear to be necessary, and cmd/link does not appear in release branches.
LGTM=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/176900044
(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
ARPHELPLINK yields 404; update the URL.
While here, also prefix the ARPREADME and ARPURLINFOABOUT URL's with the HTTP scheme to make 'em clickable links in the Add or Remove Programs listing.
LGTM=adg
R=golang-codereviews
CC=adg, golang-codereviews
https://golang.org/cl/154580045
Set correct version number at Windows installer based on
Go's Mercurial tag.
Name | Version
------------------------------------------------
Go Programming Language amd64 go1.3.3 | 1.3.3
Go Programming Language amd64 go1.2rc3 | 1.2
Go Programming Language amd64 go1.2beta1 | 1.2
Fixes#8239.
LGTM=adg
R=adg, c.emil.hessman, alex.brainman
CC=golang-codereviews
https://golang.org/cl/160950044
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
This CL adjusts code referring to src/pkg to refer to src.
Immediately after submitting this CL, I will submit
a change doing 'hg mv src/pkg/* src'.
That change will be too large to review with Rietveld
but will contain only the 'hg mv'.
This CL will break the build.
The followup 'hg mv' will fix it.
For more about the move, see golang.org/s/go14nopkg.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/134570043
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
The [568]c compilers no longer support packed structs, so
using them with -cdefs no longer works. Just commenting out
the test, rather than removing it, in case this needs to be
handled. It may be that -cdefs can go away entirely in the
future, in which case so can this directory.
LGTM=mdempsky
R=rsc, mdempsky
CC=golang-codereviews
https://golang.org/cl/136030043
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
Add gofmt.go and gofmt_test.go as they are part of the test data set.
See CL 130440043.
LGTM=dvyukov
R=golang-codereviews, dvyukov
CC=golang-codereviews
https://golang.org/cl/132820044
E.g., here's the new "go build" output:
$ go build misc/cgo/errors/issue8442.go
# command-line-arguments
could not determine kind of name for C.issue8442foo
gcc errors for preamble:
misc/cgo/errors/issue8442.go:11:19: error: unknown type name 'UNDEF'
Fixes#8442.
LGTM=iant
R=iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/129160043
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
