This test currently fails in the Android builders, with the message
pkg_test.go:64: go test -short: exec: "go": executable file not found in $PATH
(https://build.golang.org/log/39ec0da5bfb7793359e199cc8e358ca5a8257840)
I was not able to test this change, because I can't get 'gomote
create' to return an instance of anything Android. However, I will
watch the build dashboard after submitting to verify that the fix
works.
Updates #30228
Android appears to lack a 'go' command in the.
Change-Id: Ieacac7f50d19e2cfef2f5d60e79a159e55b5cfa8
Reviewed-on: https://go-review.googlesource.com/c/164097
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Elias Naur <mail@eliasnaur.com>
I hope that this will fix the tests on iOS, but 'gomote create' isn't
giving me an instance I can test with. (Please patch and test before
approving.)
Updates #15919
Updates #30228
Change-Id: I1b7cd30d5b127a1ad3243b329fa005d229f69a24
Reviewed-on: https://go-review.googlesource.com/c/163726
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <mail@eliasnaur.com>
This change preserves the ability to test misc/cgo/test in GOPATH
mode, at the cost of indirection through a 'go test' subprocess.
Updates #30228
Change-Id: I08de855e62278d30fa622b2f7478e43dd2ab0e96
Reviewed-on: https://go-review.googlesource.com/c/163418
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Work involved in getting a stack trace is divided between
runtime.Callers and runtime.CallersFrames.
Before this CL, runtime.Callers returns a pc per runtime frame.
runtime.CallersFrames is responsible for expanding a runtime frame
into potentially multiple user frames.
After this CL, runtime.Callers returns a pc per user frame.
runtime.CallersFrames just maps those to user frame info.
Entries in the result of runtime.Callers are now pcs
of the calls (or of the inline marks), not of the instruction
just after the call.
Fixes#29007Fixes#28640
Update #26320
Change-Id: I1c9567596ff73dc73271311005097a9188c3406f
Reviewed-on: https://go-review.googlesource.com/c/152537
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This was accidentally broken by CL 127755.
Fixes#29333
Change-Id: I5e92048c64a55c1699d6c38eb4dbbd51c817b820
Reviewed-on: https://go-review.googlesource.com/c/155037
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Similar to to macOS' CF* types and JNI's jobject and derived types,
the EGLDisplay type is declared as a pointer but can contain
non-pointers (see #27054).
Fix it the same way: map EGLDisplay to uintptr in Go.
Fixes#27054
RELNOTE=yes
Change-Id: I6136f8f8162687c5493b30ed324e29efe55a8fd7
Reviewed-on: https://go-review.googlesource.com/c/154417
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
CL 122575 and its successors introduced a loop calling loadDWARF,
whereas before we only called it once. Pass a single typeConv to each
call, rather than creating a new one in loadDWARF itself. Change the
maps from dwarf.Type to use string keys rather than dwarf.Type keys,
since when the DWARF is reloaded the dwarf.Type pointers will be
different. These changes permit typeConv.Type to return a consistent
value for a given DWARF type, avoiding spurious type conversion errors
due to typedefs loaded after the first loop iteration.
Fixes#27340
Change-Id: Ic33467bbfca4c54e95909621b35ba2a58216d96e
Reviewed-on: https://go-review.googlesource.com/c/152762
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The old code ignored the field alignment, and only looked at the field
offset: if the field offset required padding, cgo added padding. But
while that approach works for Go (at least with the gc toolchain) it
doesn't work for C code using packed structs. With a packed struct the
added padding may leave the struct at a misaligned position, and the
inserted alignment, which cgo is not considering, may introduce
additional, unexpected, padding. Padding that ignores alignment is not
a good idea when the struct is not packed, and Go structs are never
packed. So don't ignore alignment.
Fixes#28896
Change-Id: Ie50ea15fa6dc35557497097be9fecfecb11efd8a
Reviewed-on: https://go-review.googlesource.com/c/150602
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
An untyped constant can be defined in any input file, we shouldn't
segregate them by file.
Updates #28772
Change-Id: I0347f15236833bb511eb49f86c449ee9241b0a25
Reviewed-on: https://go-review.googlesource.com/c/151600
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
cgocall could previously invoke the race detector on an M whose P had
been retaken. The race detector would attempt to use the P-local state
from this stale P, racing with the thread that was actually wired to
that P. The result was memory corruption of ThreadSanitizer's internal
data structures that presented as hard-to-understand assertion failures
and segfaults.
Reorder cgocall so that it always acquires a P before invoking the race
detector, and add a test that stresses the interaction between cgo and
the race detector to protect against future bugs of this kind.
Fixes#27660.
Change-Id: Ide93f96a23490314d6647547140e0a412a97f0d4
Reviewed-on: https://go-review.googlesource.com/c/148717
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Updating each call in place broke when there were multiple cgo calls
used as arguments to another cgo call where some required rewriting.
Instead, rewrite calls to strings via the existing mangling mechanism,
and only substitute the top level call in place.
Fixes#28540
Change-Id: Ifd66f04c205adc4ad6dd5ee8e79e57dce17e86bb
Reviewed-on: https://go-review.googlesource.com/c/146860
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The cgo tool predefines some C types such as C.uint. Don't give an
error if the type that cgo defines does not match the type in a header file.
Fixes#26743
Change-Id: I9ed3b4c482b558d8ffa8bf61eb3209415b7a9e3c
Reviewed-on: https://go-review.googlesource.com/127356
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Ensure that we call FinishType on all the types added to the ptrs map.
We only add a key to ptrKeys once. Once we FinishType for that key,
we'll never look at that key again. But we can add a new type under that
key later, and we'll never finish it.
Make sure we add the key to the ptrKeys list every time we make the list
of types for that key non-empty.
This makes sure we FinishType each pointer type exactly once.
Fixes#26517
Change-Id: Iad86150d516fcfac167591daf5a26c38bec7d143
Reviewed-on: https://go-review.googlesource.com/126275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For unknown reasons, linking against CoreFoundation on macOS 10.10
sometimes causes mmap to ignore the hint address, which makes the Go
allocator incompatible with TSAN. Currently, the effect of this is to
run the allocator out of arena hints on the very first allocation,
causing a "too many address space collisions for -race mode" panic.
This CL skips the cgo tests that link against CoreFoundation in race
mode.
Updates #26475.
Updates #26513.
Change-Id: I52ec638c99acf5d4966e68ff0054f7679680dac6
Reviewed-on: https://go-review.googlesource.com/125304
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
In CLs 122575 and 123177 the cgo tool started explicitly looking up
typedefs. When there are two Go files using import "C", and the first
one has an incomplete typedef and the second one has a complete
version of the same typedef, then we will now record a version of the
first typedef which will not match the recorded version of the second
typedef, producing an "inconsistent definitions" error. Fix this by
silently merging incomplete typedefs with complete ones.
Fixes#26430
Change-Id: I9e629228783b866dd29b5c3a31acd48f6e410a2d
Reviewed-on: https://go-review.googlesource.com/124575
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
In Android's NDK16, jobject is now declared as:
#ifdef __cplusplus
class _jobject {};
typedef _jobject* jobject;
#else /* not __cplusplus */
typedef void* jobject;
#endif
This makes the jobject to uintptr check fail because it expects the
following definition:
struct _jobject;
typedef struct _jobject *jobject;
Update the type check to handle that new type definition in both C and
C++ modes.
Fixes#26213
Change-Id: Ic36d4a5176526998d2d5e4e404f8943961141f7a
GitHub-Last-Rev: 42037c3c58
GitHub-Pull-Request: golang/go#26221
Reviewed-on: https://go-review.googlesource.com/122217
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TARGET_OS_OSX is the right macro, but it also was only introduced
in 1.12. For 1.11 and earlier a reasonable substitution is
TARGET_OS_IPHONE == 0.
Update #24161
Update #26355
Change-Id: I5f43c463d14fada9ed1d83cc684c7ea05d94c5f3
Reviewed-on: https://go-review.googlesource.com/124075
Run-TryBot: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The test in CL 123715 doesn't work on iOS, it needs to use a different
version scheme to determine whether SecKeyAlgorithm and friends exist.
Restrict the old version test to OSX only.
The same problem occurs on iOS: the functions tested don't exist before
iOS 10. But we don't have builders below iOS 10, so it isn't a big issue.
If we ever get older builders, or someone wants to run all.bash on an
old iOS, they'll need to figure out the right incantation.
Update #24161
Update #26355
Change-Id: Ia3ace86b00486dc172ed00c0c6d668a95565bff7
Reviewed-on: https://go-review.googlesource.com/123959
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The test uses functions from C that were introduced in OSX 1.12.
Include stubs for those functions when compiling for 1.11 and earlier.
This test really a compile-time test, it doesn't matter much what the
executed code actually does.
Use a nasty #define hack to work around the fact that cgo doesn't
support static global variables.
Update #24161Fixes#26355
Change-Id: Icf6f7bc9b6b36cacc81d5d0e033a2ebaff7e0298
Reviewed-on: https://go-review.googlesource.com/123715
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Two fixes:
1) Typedefs of the bad typedefs should also not be rewritten to the
underlying type. They shouldn't just be uintptr, though, they should
retain the C naming structure. For example, in C:
typedef const __CFString * CFStringRef;
typedef CFStringRef SecKeyAlgorithm;
we want the Go:
type _Ctype_CFStringRef uintptr
type _Ctype_SecKeyAlgorithm = _Ctype_CFStringRef
2) We need more types than just function arguments/return values.
At least we need types of global variables, so when we see a reference to:
extern const SecKeyAlgorithm kSecKeyAlgorithmECDSASignatureDigestX962SHA1;
we know that we need to investigate the type SecKeyAlgorithm.
Might as well just find every typedef and check the badness of all of them.
This requires looping until a fixed point of known types is reached.
Usually it takes just 2 iterations, sometimes 3.
Fixes#24161
Change-Id: I32ca7e48eb4d4133c6242e91d1879636f5224ea9
Reviewed-on: https://go-review.googlesource.com/123177
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We need to determine whether arguments to and return values from C
functions are "bad" typedef'd pointer types which need to be uintptr
on the Go side.
The type of those arguments are not specified explicitly. As a result,
we never look through the C declarations for the GetTypeID functions
associated with that type, and never realize that they are bad.
However, in another function in the same package there might be an
explicit reference. Then we end up with the declaration being uintptr
in one file and *struct{...} in another file. Badness ensues.
Fix this by doing a 2-pass algorithm. In the first pass, we run as
normal, but record all the argument and result types we see. In the
second pass, we include those argument types also when reading the C
types.
Fixes#24161
Change-Id: I8d727e73a2fbc88cb9d9899f8719ae405f59f753
Reviewed-on: https://go-review.googlesource.com/122575
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before GCC 8 C code like
const unsigned long long int neg = (const unsigned long long) -1;
void f(void) { static const double x = (neg); }
would get an error "initializer element is not constant". In GCC 8 and
later it does not.
Because a value like neg, above, can not be used as a general integer
constant, this causes cgo to conclude that it is a floating point
constant. The way that cgo handles floating point values then causes
it to get the wrong value for it: 18446744073709551615 rather than -1.
These are of course the same value when converted to int64, but Go
does not permit that kind of conversion for an out-of-range constant.
This CL side-steps the problem by treating floating point constants
with integer type as they would up being treated before GCC 8: as
variables rather than constants.
Fixes#26066
Change-Id: I6f2f9ac2fa8a4b8218481b474f0b539758eb3b79
Reviewed-on: https://go-review.googlesource.com/121035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is the same retry loop we use in _cgo_try_pthread_create in runtime/cgo.
Fixes#25078
Change-Id: I7ef4d4fc7fb89cbfb674c4f93cbdd7a033dd8983
Reviewed-on: https://go-review.googlesource.com/121096
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Current versions of gccgo issue a duplicate definition error when both
a definition and an empty declaration occur. Use build tags to avoid
that case for the issue9400 subdirectory.
Change-Id: I18517af87bab05e9ca43f2f295459cf34347c317
Reviewed-on: https://go-review.googlesource.com/119896
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use more cryptic names for local variables inside C function wrappers.
Fixes#23356
Change-Id: Ia6a0218f27a13be14f589b1a0facc9683d22ff56
Reviewed-on: https://go-review.googlesource.com/86495
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This avoids name conflicts when two identical packages use cgo.
This can happen in practice when the same package is vendored multiple
times in a single build.
Fixes#23555
Change-Id: I9f0ec6db9165dcf9cdf3d314c668fee8ada18f9c
Reviewed-on: https://go-review.googlesource.com/118739
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#25143
Change-Id: Ide654fe70651fda827cdeeaaa73d2a1f8aefd7e7
Reviewed-on: https://go-review.googlesource.com/110159
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The test has been flaky, probably due to EAGAIN, but let's find out
for sure.
Updates #25078
Change-Id: I5a5b14bfc52cb43f25f07ca7d207b61ae9d4f944
Reviewed-on: https://go-review.googlesource.com/109359
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
bytes.IndexByte is heavily optimized. Use it in findnull.
This is second attempt, similar to CL97523.
In this version we never call IndexByte on region of memory,
that crosses page boundary. A bit slower than CL97523,
but still fast:
name old time/op new time/op delta
GoString-6 164ns ± 2% 118ns ± 0% -28.00% (p=0.000 n=10+6)
findnull is also used in gostringnocopy,
which is used in many hot spots in the runtime.
Fixes#23830
Change-Id: Id843dd4f65a34309d92bdd8df229e484d26b0cb2
Reviewed-on: https://go-review.googlesource.com/98015
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This reverts commit 7365fac2db.
Reason for revert: breaks the build on some architectures, reading unmapped pages?
Change-Id: I3a8c02dc0b649269faacea79ecd8213defa97c54
Reviewed-on: https://go-review.googlesource.com/97995
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
bytes.IndexByte is heavily optimized.
Use it in findnull.
name old time/op new time/op delta
GoString-8 65.5ns ± 1% 40.2ns ± 1% -38.62% (p=0.000 n=19+19)
findnull is also used in gostringnocopy,
which is used in many hot spots in the runtime.
Fixes#23830
Change-Id: I2e6cb279c7d8078f8844065de684cc3567fe89d7
Reviewed-on: https://go-review.googlesource.com/97523
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This replaces frame size -4/-8 with the NOFRAME flag in mips and
mips64 assembly.
This was automated with:
sed -i -e 's/\(^TEXT.*[A-Z]\),\( *\)\$-[84]/\1|NOFRAME,\2$0/' $(find -name '*_mips*.s')
Plus a manual fix to mkduff.go.
The go binary is identical on both architectures before and after this
change.
Change-Id: I0310384d1a584118c41d1cd3a042bb8ea7227efb
Reviewed-on: https://go-review.googlesource.com/92044
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This replaces frame size -8 with the NOFRAME flag in arm64 assembly.
This was automated with:
sed -i -e 's/\(^TEXT.*[A-Z]\),\( *\)\$-8/\1|NOFRAME,\2$0/' $(find -name '*_arm64.s')
Plus a manual fix to mkduff.go.
The go binary is identical before and after this change.
Change-Id: I0310384d1a584118c41d1cd3a042bb8ea7227efa
Reviewed-on: https://go-review.googlesource.com/92043
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This replaces frame size -4 with the NOFRAME flag in arm assembly.
This was automated with:
sed -i -e 's/\(^TEXT.*[A-Z]\),\( *\)\$-4/\1|NOFRAME,\2$0/' $(find -name '*_arm.s')
Plus three manual comment changes found by:
grep '\$-4' $(find -name '*_arm.s')
The go binary is identical before and after this change.
Change-Id: I0310384d1a584118c41d1cd3a042bb8ea7227ef9
Reviewed-on: https://go-review.googlesource.com/92042
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 49490 fixed a warning when compiling the C code generated by cgo,
but it introduced typedef conflicts in Go code that cgo is supposed to
avoid.
Original CL description:
cmd/cgo: fix for function taking pointer typedef
Fixes#19832
Updates #19832Fixes#23720
Change-Id: I22a732db31be0b4f7248c105277ab8ee44ef6cfb
Reviewed-on: https://go-review.googlesource.com/92455
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The dlopen function returns an opaque handle, and it is possible for
it to look like a Go pointer, causing garbage collector and cgo
confusion.
Fixes#23663
Change-Id: Id080e2bbcee8cfa7ac4a457a927f96949eb913f8
Reviewed-on: https://go-review.googlesource.com/91596
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The jobject type is declared as a pointer, but some JVMs
(Dalvik, ART) store non-pointer values in them. In Go, we must
use uintptr instead of a real pointer for these types.
This is similar to the CoreFoundation types on Darwin which
were "fixed" in CL 66332.
Update #22906
Update #21897
RELNOTE=yes
Change-Id: I0d4c664501d89a696c2fb037c995503caabf8911
Reviewed-on: https://go-review.googlesource.com/81876
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
