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>
This test is slightly flaky on the s390x builder and I suspect that
the 100ms timeout is a little too optimistic when the VM is starved.
Increase the timeout to 5s to match the other part of the test.
Fixes#26231.
Change-Id: Ia6572035fb3efb98749f2c37527d250a4c779477
Reviewed-on: https://go-review.googlesource.com/122315
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Otherwise it is possible that msan will consider the C result to be
partially initialized, which may cause msan to think that the Go stack
is partially uninitialized. The compiler will never mark the stack as
initialized, so without this CL it is possible for stack addresses to
be passed to msanread, which will cause a false positive error from msan.
Fixes#26209
Change-Id: I43a502beefd626eb810ffd8753e269a55dff8248
Reviewed-on: https://go-review.googlesource.com/122196
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
Add a test by making misc/cgo/testshared/src/trivial.go marginally less
trivial.
Fixes#25970.
Change-Id: I8815d0c56b8850fcdbf9b45f8406f37bd21b6865
Reviewed-on: https://go-review.googlesource.com/120235
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@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>
With latest gcc (7.3.0), misc/cgo/testsanitizer test will fail with reporting sigmentation
fault when running tsan test. On arm64, tsan is not supported currently and only msan test
can be run. So skip tsan test on arm64.
What needs to be pointed out is that msan test can be really run when setting clang
as c/c++ complier.
Fixes#25601
Change-Id: I6ab1a8d9edd243e2ee00ee40bc0abd6a0e6a125c
Reviewed-on: https://go-review.googlesource.com/114857
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@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>
When using plugins with goroutines calling cgo, we hit a case where
an intermittent SIGSEGV occurs when referencing an address that is based
on r2 (TOC address). When the failure can be generated in gdb, the
contents of r2 is wrong even though the value in the current stack's
slot for r2 is correct. So that means it somehow switched to start
running the code in this function without passing through the beginning
of the function which had the correct value of r2 and stored it there.
It was noted that in runtime.gogo when the state is restored from
gobuf, r2 is not restored from its slot on the stack. Adding the
instruction to restore r2 prevents the SIGSEGV.
This adds a testcase under testplugin which reproduces the problem if
the program is run multiple times. The team who reported this problem
has verified it fixes the issue on their larger, more complex
application.
Fixes#25756
Change-Id: I6028b6f1f8775d5c23f4ebb57ae273330a28eb8f
Reviewed-on: https://go-review.googlesource.com/117515
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL removes the rundircmpout action completely
because it is not used anywhere.
The run case already looks for output files. Rename the cmpout action
mentioned in tests to the run action and remove "cmpout" from run.go.
Change-Id: I835ceb70082927f8e9360e0ea0ba74f296363ab3
Reviewed-on: https://go-review.googlesource.com/115575
Run-TryBot: Yury Smolsky <yury@smolsky.by>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
If X depends on Y and X was installed but Y is only present in the cache
(as happens when you "go install X") then we should report X as up-to-date,
not as stale.
This applies whether X is a package or a main binary.
Fixes#24558.
Fixes#23818.
Change-Id: I26a0b375b1f7f7ac909cc0db68e92f4e04529208
Reviewed-on: https://go-review.googlesource.com/107957
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We were using absolute paths in the #line directives in the export
header file. This makes the header file change if you move GOPATH.
The absolute paths aren't helpful for the final user, which is some C
program elsewhere.
Fixes#24945
Change-Id: I2da32c9b477df578bd5087435a03fe97abe462e3
Reviewed-on: https://go-review.googlesource.com/108315
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We were using file descriptor 100, which requires the Linux kernel to
grow the fdtable size. That step may sometimes require a long time,
causing the test to fail. Switch to file descriptor 30, which should
not require growing the fdtable.
Fixes#23784
Change-Id: I3ac40d6f8569c70d34b470cfca34eff149bf8229
Reviewed-on: https://go-review.googlesource.com/108537
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Fixes#14327
Much of the code is based on the linux/amd64 code that implements these
build modes, and code is shared where possible.
Change-Id: Ia510f2023768c0edbc863aebc585929ec593b332
Reviewed-on: https://go-review.googlesource.com/93875
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When there are plugins, there may not be a unique copy of runtime
functions like goexit, mcall, etc. So identifying them by entry
address is problematic. Instead, keep track of each special function
using a field in the symbol table. That way, multiple copies of
the same runtime function will be treated identically.
Fixes#24351Fixes#23133
Change-Id: Iea3232df8a6af68509769d9ca618f530cc0f84fd
Reviewed-on: https://go-review.googlesource.com/100739
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
Increase the sleep and wait for up to 2 seconds for the dup2.
Apparently it can sometimes take a long time.
Fixes#23784
Change-Id: I929530b057bbcd842b28a7640c39dd68d719ff7d
Reviewed-on: https://go-review.googlesource.com/93895
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
Both gcc and clang accept an option -fplugin=code.so to load
a plugin from the ELF shared object file code.so.
Obviously that plugin can then do anything it wants
during the build. This is contrary to the goal of "go get"
never running untrusted code during the build.
(What happens if you choose to run the result of
the build is your responsibility.)
Disallow this behavior by only allowing a small set of
known command-line flags in #cgo CFLAGS directives
(and #cgo LDFLAGS, etc).
The new restrictions can be adjusted by the environment
variables CGO_CFLAGS_ALLOW, CGO_CFLAGS_DISALLOW,
and so on. See the documentation.
In addition to excluding cgo-defined flags, we also have to
make sure that when we pass file names on the command
line, they don't look like flags. So we now refuse to build
packages containing suspicious file names like -x.go.
A wrinkle in all this is that GNU binutils uniformly accept
@foo on the command line to mean "if the file foo exists,
then substitute its contents for @foo in the command line".
So we must also reject @x.go, flags and flag arguments
beginning with @, and so on.
Fixes#23672, CVE-2018-6574.
Change-Id: I59e7c1355155c335a5c5ae0d2cf8fa7aa313940a
Reviewed-on: https://team-review.git.corp.google.com/209949
Reviewed-by: Ian Lance Taylor <iant@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>
Introduce GOANDROID_ADB_FLAGS for additional flags to adb invocations.
With GOANDROID_ADG_FLAGS, the Android builders can distinguish between
emulator and device builds.
Change-Id: I11729926a523ee27f6a3795cb2cfb64a9454f0a5
Reviewed-on: https://go-review.googlesource.com/88795
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The cgo checker was issuing an error with cgocheck=2 when a timer
bucket was stored in a pollDesc. The pollDesc values are allocated
using persistentalloc, so they are not in the Go heap. The code is OK
since timer bucket pointers point into a global array, and as such are
never garbage collected or moved.
Mark timersBucket notinheap to avoid the problem. timersBucket values
only occur in the global timers array.
Fixes#23435
Change-Id: I835f31caafd54cdacc692db5989de63bb49e7697
Reviewed-on: https://go-review.googlesource.com/87637
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
After CL 69831, addTransitiveLinkDeps ensures that all dependencies of
a link appear in Deps. We no longer need to traverse through all
actions to find them. And the old scheme of looking through all the
actions and assuming we would see shared library actions before
libraries they depend on no longer works.
Now that we have complete deps, change to a simpler scheme in which we
find the shared libraries in the deps, and then use that to sort the
deps into archives and shared libraries.
Fixes#22224
Change-Id: I14fcc773ac59b6f5c2965cc04d4ed962442cc89e
Reviewed-on: https://go-review.googlesource.com/87497
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>
Fixed by CL 76025 yesterday, without realizing it:
the testshared and testplugin builds of separate iface_i
packages were colliding incorrectly in the cache.
Including the build directory fixes that.
Fixes#22571.
Change-Id: Id8193781c67c3150823dc1f48eae781dfe3702fb
Reviewed-on: https://go-review.googlesource.com/76371
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This reverts commit 08f19bbde1.
Reason for revert:
The changed transformation takes effect on a larger set
of code snippets than expected.
For example, this:
func foo() {
// Comment
bar()
}
becomes:
func foo() {
// Comment
bar()
}
This is an unintended consequence.
Change-Id: Ifca88d6267dab8a8170791f7205124712bf8ace8
Reviewed-on: https://go-review.googlesource.com/81335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Some C types are declared as pointers, but C code
stores non-pointers in them. When the Go garbage
collector sees such a pointer, it gets unhappy.
Instead, for these types represent them on the Go
side with uintptr.
We need this change to handle Apple's CoreFoundation
CF*Ref types. Users of these types might need to
update their code like we do in root_cgo_darwin.go.
The only change that is required under normal
circumstances is converting some nils to 0.
A go fix module is provided to help.
Fixes#21897
RELNOTE=yes
Change-Id: I9716cfb255dc918792625f42952aa171cd31ec1b
Reviewed-on: https://go-review.googlesource.com/66332
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Permit the C preamble to use the _GoString_ type. Permit Go code to
pass string values directly to those C types. Add accessors for C
code to retrieve sizes and pointers.
Fixes#6907
Change-Id: I190c88319ec88a3ef0ddb99f342a843ba69fcaa3
Reviewed-on: https://go-review.googlesource.com/70890
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Also, with this change, error locations don't print absolute positions
in [] brackets following positions relative to line directives. To get
the absolute positions as well, specify the -L flag.
Fixes#22660.
Change-Id: I9ecfa254f053defba9c802222874155fa12fee2c
Reviewed-on: https://go-review.googlesource.com/77090
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The go repository contains a mix of github.com/golang/go/issues/xxxxx
and golang.org/issues/xxxxx URLs for references to issues in the issue
tracker. We should use one for consistency, and golang.org is preferred
in case the project moves the issue tracker in the future.
This reasoning is taken from a comment Sam Whited left on a CL I
recently opened: https://go-review.googlesource.com/c/go/+/73890.
In that CL I referenced an issue using its github.com URL, because other
tests in the file I was changing contained references to issues using
their github.com URL. Sam Whited left a comment on the CL stating I
should change it to the golang.org URL.
If new code is intended to reference issues via golang.org and not
github.com, existing code should be updated so that precedence exists
for contributors who are looking at the existing code as a guide for the
code they should write.
Change-Id: I3b9053fe38a1c56fc101a8b7fd7b8f310ba29724
Reviewed-on: https://go-review.googlesource.com/75673
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL makes "go install" behave the way many users expect:
install only the things named on the command line.
Future builds still run as fast, thanks to the new build cache (CL 75473).
To install dependencies as well (the old behavior), use "go install -i".
Actual definitions aside, what most users know and expect of "go install"
is that (1) it installs what you asked, and (2) it's fast, unlike "go build".
It was fast because it installed dependencies, but installing dependencies
confused users repeatedly (see for example #5065, #6424, #10998, #12329,
"go build" and "go test" so that they could be "fast" too, but that only
created new opportunities for confusion. We also had to add -installsuffix
and then -pkgdir, to allow "fast" even when dependencies could not be
installed in the usual place.
The recent introduction of precise content-based staleness logic means that
the go command detects the need for rebuilding packages more often than it
used to, with the consequence that "go install" rebuilds and reinstalls
dependencies more than it used to. This will create more new opportunities
for confusion and will certainly lead to more issues filed like the ones
listed above.
CL 75743 introduced a build cache, separate from the install locations.
That cache makes all operations equally incremental and fast, whether or
not the operation is "install" or "build", and whether or not "-i" is used.
Installing dependencies is no longer necessary for speed, it has confused
users in the past, and the more accurate rebuilds mean that it will confuse
users even more often in the future. This CL aims to end all that confusion
by not installing dependencies by default.
By analogy with "go build -i" and "go test -i", which still install
dependencies, this CL introduces "go install -i", which installs
dependencies in addition to the things named on the command line.
Fixes#5065.
Fixes#6424.
Fixes#10998.
Fixes#12329.
Fixes#18981.
Fixes#22469.
Another step toward #4719.
Change-Id: I3d7bc145c3a680e2f26416e182fa0dcf1e2a15e5
Reviewed-on: https://go-review.googlesource.com/75850
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL adds an automatic, limited "go vet" to "go test".
If the building of a test package fails, vet is not run.
If vet fails, the test is not run.
The goal is that users don't notice vet as part of the "go test"
process at all, until vet speaks up and says something important.
This should help users find real problems in their code faster
(vet can just point to them instead of needing to debug a
test failure) and expands the scope of what kinds of things
vet can help with.
The "go vet" runs in parallel with the linking of the test binary,
so for incremental builds it typically does not slow the overall
"go test" at all: there's spare machine capacity during the link.
all.bash has less spare machine capacity. This CL increases
the time for all.bash on my laptop from 4m41s to 4m48s (+2.5%)
To opt out for a given run, use "go test -vet=off".
The vet checks used during "go test" are a subset of the full set,
restricted to ones that are 100% correct and therefore acceptable
to make mandatory. In this CL, that set is atomic, bool, buildtags,
nilfunc, and printf. Including printf is debatable, but I want to
include it for now and find out what needs to be scaled back.
(It already found one real problem in package os's tests that
previous go vet os had not turned up.)
Now that we can rely on type information it may be that printf
should make its function-name-based heuristic less aggressive
and have a whitelist of known print/printf functions.
Determining the exact set for Go 1.10 is #18085.
Running vet also means that programs now have to type-check
with both cmd/compile and go/types in order to pass "go test".
We don't start vet until cmd/compile has built the test package,
so normally the added go/types check doesn't find anything.
However, there is at least one instance where go/types is more
precise than cmd/compile: declared and not used errors involving
variables captured into closures.
This CL includes a printf fix to os/os_test.go and many declared
and not used fixes in the race detector tests.
Fixes#18084.
Change-Id: I353e00b9d1f9fec540c7557db5653e7501f5e1c9
Reviewed-on: https://go-review.googlesource.com/74356
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL adds caching of successful test results, keyed by the
action ID of the test binary and its command line arguments.
Suppose you run:
go test -short std
<edit a typo in a comment in math/big/float.go>
go test -short std
Before this CL, the second go test would re-run all the tests
for the std packages. Now, the second go test will use the cached
result immediately (without any compile or link steps) for any
packages that do not transitively import math/big, and then
it will, after compiling math/big and seeing that the .a file didn't
change, reuse the cached test results for the remaining packages
without any additional compile or link steps.
Suppose that instead of editing a typo you made a substantive
change to one function, but you left the others (including their
line numbers) unchanged. Then the second go test will re-link
any of the tests that transitively depend on math/big, but it still
will not re-run the tests, because the link will result in the same
test binary as the first run.
The only cacheable test arguments are:
-cpu
-list
-parallel
-run
-short
-v
Using any other test flag disables the cache for that run.
The suggested argument to mean "turn off the cache" is -count=1
(asking "please run this 1 time, not 0").
There's an open question about re-running tests when inputs
like environment variables and input files change. For now we
will assume that users will bypass the test cache when they
need to do so, using -count=1 or "go test" with no arguments.
This CL documents the new cache but also documents the
previously-undocumented distinction between "go test" with
no arguments (now called "local directory mode") and with
arguments (now called "package list mode"). It also cleans up
a minor detail of package list mode buffering that used to change
whether test binary stderr was sent to go command stderr based
on details like exactly how many packages were listed or
how many CPUs the host system had. Clearly the file descriptor
receiving output should not depend on those, so package list mode
now consistently merges all output to stdout, where before it
mostly did that but not always.
Fixes#11193.
Change-Id: I120edef347b9ddd5b10e247bfd5bd768db9c2182
Reviewed-on: https://go-review.googlesource.com/75631
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
To improve readability when exported fields are removed,
forbid the printer from emitting an empty line before the first comment
in a const, var, or type block.
Also, when printing the "Has filtered or unexported fields." message,
add an empty line before it to separate the message from the struct
or interfact contents.
Before the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
After the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
Fixes#18264
Change-Id: I9fe17ca39cf92fcdfea55064bd2eaa784ce48c88
Reviewed-on: https://go-review.googlesource.com/71990
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This cuts 6 seconds off all.bash with the new go command.
Not a ton, but also an easy 6 seconds to grab.
The -tags=use_go_run in the misc/cgo tests is just some
go command flag that will make run.go use go run,
but without making everything look stale.
(Those tests have relative imports,
so go tool compile+link is not enough.)
Change-Id: I43bf4bb661d3adde2b2d4aad5e8f64b97bc69ba9
Reviewed-on: https://go-review.googlesource.com/73994
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL changes the go command to base all its rebuilding decisions
on the content of the files being processed and not their file system
modification times. It also eliminates the special handling of release
toolchains, which were previously considered always up-to-date
because modification time order could not be trusted when unpacking
a pre-built release.
The go command previously tracked "build IDs" as a backup to
modification times, to catch changes not reflected in modification times.
For example, if you remove one .go file in a package with multiple .go
files, there is no modification time remaining in the system that indicates
that the installed package is out of date. The old build ID was the hash
of a list of file names and a few other factors, expected to change if
those factors changed.
This CL moves to using this kind of build ID as the only way to
detect staleness, making sure that the build ID hash includes all
possible factors that need to influence the rebuild decision.
One such factor is the compiler flags. As of this CL, if you run
go build -gcflags -N cmd/gofmt
you will get a gofmt where every package is built with -N,
regardless of what may or may not be installed already.
Another such factor is the linker flags. As of this CL, if you run
go install myprog
go install -ldflags=-s myprog
the second go install will now correctly build a new myprog with
the updated linker flags. (Previously the installed myprog appeared
up-to-date, because the ldflags were not included in the build ID.)
Because we have more precise information we can also validate whether
the target of a "go test -c" operation is already the right binary and
therefore can avoid a rebuild.
This CL sets us up for having a more general build artifact cache,
maybe even a step toward not having a pkg directory with .a files,
but this CL does not take that step. For now the result of go install
is the same as it ever was; we just do a better job of what needs to
be installed.
This CL does slow down builds a small amount by reading all the
dependent source files in full. (The go command already read the
beginning of every dependent source file to discover build tags
and imports.) On my MacBook Pro, before this CL all.bash takes
3m58s, while after this CL and a few optimizations stacked above it
all.bash takes 4m28s. Given that CL 73850 cut 1m43s off the all.bash
time earlier today, we can afford adding 30s back for now.
More optimizations are planned that should make the go command
more efficient than it was even before this CL.
Fixes#15799.
Fixes#18369.
Fixes#19340.
Fixes#21477.
Change-Id: I10d7ca0e31ca3f58aabb9b1f11e2e3d9d18f0bc9
Reviewed-on: https://go-review.googlesource.com/73212
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The upcoming CL 73212 will see through mtime modifications.
Change the underlying file too.
Change-Id: Ib23b4136a62ee87bce408b76bb0385451ae7dcd2
Reviewed-on: https://go-review.googlesource.com/74130
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Both the linker and the plugin package were inconsistent
about when they applied the path encoding defined in
objabi.PathToPrefix. As a result, only some symbols from
a package path that required encoding were being found.
So always encoding the path.
Fixes#22295
Change-Id: Ife86c79ca20b2e9307008ed83885e193d32b7dc4
Reviewed-on: https://go-review.googlesource.com/72390
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Running test.bash goes from 30s to 10s on a linux workstation.
(The coming pkg cache work in cmd/go would presumably do the same thing,
but this makes all.bash faster today.)
Change-Id: I8c9b0400071a412fce55b386e939906bb1c1d84d
Reviewed-on: https://go-review.googlesource.com/72330
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently we look to see if the main.main symbol address is in the
module data text range. This requires access to the main.main
symbol, which usually the runtime has, but does not when building
a plugin.
To avoid a dynamic relocation to main.main (which I haven't worked
out how to have the linker generate on darwin), stop using the
symbol. Instead record a boolean in the moduledata if the module
has the main function.
Fixes#22175
Change-Id: If313a118f17ab499d0a760bbc2519771ed654530
Reviewed-on: https://go-review.googlesource.com/69370
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Starting in gcc 6, -pie is passed to the linker by default
on some platforms, including ppc64le. If the objects
being linked are not built for -pie then in some cases the
executable could be in error. To avoid that problem, -no-pie
should be used with gcc to override the default -pie option
and generate a correct executable that can be run without error.
Fixes#22126
Change-Id: I4a052bba8b9b3bd6706f5d27ca9a7cebcb504c95
Reviewed-on: https://go-review.googlesource.com/70072
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Everything got a bit tangled together in b.action1.
Try to tease things apart again.
In general this is a refactoring of the existing code, with limited
changes to the effect of the code.
The main additional change is to complete a.Deps for link actions.
That list now directly contains all the inputs the linker will attempt
to read, eliminating the need for a transitive traversal of the entire
action graph to find those. The comepleteness of a.Deps will be
important when we eventually use it to decide whether an cached
action output can be reused.
all.bash passes, but it's possible I've broken some subtety of
buildmode=shared again. Certainly that code took the longest
to get working.
Change-Id: I34e849eda446dca45a9cfce02b07bec6edb6d0d4
Reviewed-on: https://go-review.googlesource.com/69831
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Updates #11058
Change-Id: I2a8bf4403b680ab8bf06fff18291f3bf67261e27
Reviewed-on: https://go-review.googlesource.com/69090
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Otherwise we end up with testp?.exe files after the tests run.
Updates #11058
Change-Id: Ieccfc42da6192622bdab1f9a411ccd50bb59fd5b
Reviewed-on: https://go-review.googlesource.com/68770
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestUnexportedSymbols requires dup2 that
my gcc installation does not have.
TestSignalHandlersWithNotify fails with:
undefined: syscall.SIGIO.
TestSignalHandlers fails with:
sched.h: No such file or directory.
TestExportedSymbolsWithDynamicLoad fails with:
dlfcn.h: No such file or directory.
Also add t.Helper calls to better error messages.
Updates #11058
Change-Id: I7eb514968464256b8337e45f57fcb7d7fe0e4693
Reviewed-on: https://go-review.googlesource.com/68410
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Moves type symbol name mangling out of the object reader
and into a separate pass. Requires some care, as changing
the name of a type may require dealing with duplicate
symbols for the first time.
Disables DWARF for both plugins and programs that use plugin.Open,
because type manging is currently incompatible with the go.info.*
symbol generator in cmd/link. (It relies on the symbol names to
find type information.) A future fix for this would be moving the
go.info.* generation into the compiler, with the logic we use
for generating the type.* symbols.
Fixes#19529
Change-Id: I75615f8bdda86ff9e767e536d9aa36e15c194098
Reviewed-on: https://go-review.googlesource.com/67312
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a step toward using cached build artifacts: the importcfg
will direct the compiler and linker to read them right from the cache
if necessary. However, this CL does not have a cache yet, so it still
reads them from the usual install location or build location.
Even so, this fixes a long-standing issue that -I and -L (no longer used)
are not expressive enough to describe complex GOPATH setups.
Shared libraries are handled enough that all.bash passes, but
there may still be more work to do here. If so, tests and fixes
can be added in follow-up CLs.
Gccgo will need updating to support -importcfg as well.
Fixes#14271.
Change-Id: I5c52a0a5df0ffbf7436e1130c74e9e24fceff80f
Reviewed-on: https://go-review.googlesource.com/56279
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When rewriting loads and stores accessing global variables to use the
GOT we were making use of REGTMP (R10). Unfortunately loads and stores
with large offsets (larger than 20-bits) were also using REGTMP,
causing it to be clobbered and subsequently a segmentation fault.
This can be fixed by using REGTMP2 (R11) for the rewrite. This is fine
because REGTMP2 only has a couple of uses in the assembler (division,
high multiplication and storage-to-storage instructions). We didn't
use REGTMP2 originally because it used to be used more frequently,
in particular for stores of constants to memory. However we have now
eliminated those uses.
This was found while writing a test case for CL 63030. That test case
is included in this CL.
Change-Id: I13956f1f3ca258a7c8a7ff0a7570d2848adf7f68
Reviewed-on: https://go-review.googlesource.com/65011
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It's not needed, and the current expectation is that it will go away
in the future.
Change-Id: I5f46800e748d9ffa484bda6d1738290c8e00ac2b
Reviewed-on: https://go-review.googlesource.com/63751
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
rune has a well-defined size, but C.int is implementation-specified.
Using one as the other should require an explicit conversion.
updates #13467
Change-Id: I53ab2478427dca790efdcc197f6b8d9fbfbd1847
Reviewed-on: https://go-review.googlesource.com/63730
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I had passed 1 instead of 2 to the SplitAfterN call in
errorstest.check, so all of the cases were erroneously falling through
to the non-regexp case (and passing even if the actual error didn't
match).
Now, we use bytes.HasSuffix to check for the non-regexp case, so we
will not incorrectly match a regexp comment to the non-regexp case.
updates #13467
Change-Id: Ia6be928a495425f2b7bae5001bd01346e115dcfa
Reviewed-on: https://go-review.googlesource.com/63692
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes the test easier to run in isolation and easier to change,
and simplifies the code to run the tests in parallel.
updates #13467
Change-Id: I5622b5cc98276970347da18e95d071dbca3c5cc1
Reviewed-on: https://go-review.googlesource.com/63276
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, test7978 failed if the user did not invoke it with
GOTRACEBACK=2 already set in their environment. Environment-sensitive
test are awkward, and in this case there is a very simple workaround:
set the traceback level to the necessary value explicitly.
Change-Id: I7d576f24138aa8a41392148eae11bbeaef558573
Reviewed-on: https://go-review.googlesource.com/63275
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 62593 broken TestExportedSymbols and TestUnexportedSymbols
because it started executing android test binary on host.
Make them run on android.
Hopefully fixes android build.
Change-Id: Ic0bb9f0cbbefca23828574282caa33a03ef72431
Reviewed-on: https://go-review.googlesource.com/62830
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Change-Id: Ib35bb7fc9c5b4ccc9b8e1bd16443e0b307be9406
Reviewed-on: https://go-review.googlesource.com/62593
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#21809
Change-Id: Ic43077c6bea3c7cdc9611e74abf07b6deab70433
Reviewed-on: https://go-review.googlesource.com/62670
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: Id1b5939cfcd210a0cb5f61915ce2d077c7fcec11
Reviewed-on: https://go-review.googlesource.com/62592
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The noopt builder sets GO_GCFLAGS when building the standard library.
Set it when building plugins to ensure the -shared packages built for it
have the same inlining in the export data (and thus the same package
version).
Tested locally with GO_GCFLAGS="-N -l" ./all.bash
Fixes#17937
Change-Id: Id037cfbf4af744c05c47bdc58eea60a5dba69533
Reviewed-on: https://go-review.googlesource.com/62511
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
1. remove broken verification
The runtime check assumes that no-pcln symbol entry have zero value,
but the linker emit no entries if the symbol is no-pcln.
As a result, if there are no-pcln symbols at the very end of pcln
table, it will panic.
2. correct condition of export
Handle special chracters in pluginpath correcty.
Export "go.itab.*", so different plugins can share the same itab.
Fixes#18190
Change-Id: Ia4f9c51d83ce8488a9470520f1ee9432802cfc1d
Reviewed-on: https://go-review.googlesource.com/61091
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Along the way, track bad modules. Make sure they don't end up on
the active modules list, and aren't accidentally reprocessed as
new plugins.
Fixes#19004
Change-Id: I8a5e7bb11f572f7b657a97d521a7f84822a35c07
Reviewed-on: https://go-review.googlesource.com/61171
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It is common to have multiple plugins built from ephemeral
source files all with the same name:
# generate main.go
go build -buildmode=plugin -o=p1.so main.go
# rm main.go, generate new main.go
go build -buildmode=plugin -o=p2.so main.go
...
These different plugins currently have the same build ID,
and hence the same package path. This means only one can be
loaded.
To remove this restriction, this commit adds the contents of the
main package source files to the plugin hash.
Fixes#19358
Change-Id: Icd42024b085feb29c09c2771aaecb85f8b528dd3
Reviewed-on: https://go-review.googlesource.com/61170
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When compiling a plugin, package main gets a new name so as not to
conflict with the main package in the host binary, or any other
plugins. It is already defined by cmd/go, and used by cmd/link when
filling out the "" package placeholder in symbols.
With this CL, the plugin-specific name for main is also passed to
cmd/compile's -p flag. This is used to fill out the pkgpath field
of types, and ensures that two types defined in two different plugin
mains with the same name will not be mistaken for one another at
runtime.
Fixes#21386
Change-Id: I8a646d8d7451caff533fe0007343ea8b8e1704ed
Reviewed-on: https://go-review.googlesource.com/60910
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The approach of https://golang.org/cl/43476 turned out incorrect.
The problem is that the sniff introduced by the CL only work for simple
expression. And when it fails it fallback to uint64, not int64, which
breaks backward compatibility.
In this CL, we use DWARF for guessing kind instead. That should be more
reliable than previous approach. And importanly, it fallbacks to int64 even
if it fails to guess kind.
Fixes#21708
Change-Id: I39a18cb2efbe4faa9becdcf53d5ac68dba180d46
Reviewed-on: https://go-review.googlesource.com/60510
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, cgo supports only macros which can be reduced to constants
or variables. The CL addresses remaining parts, macros which can be
represented as niladic functions.
The basic idea is simple:
1. make a thin wrapper function per macros.
2. replace macro expansions with function calls.
Fixes#10715Fixes#18720
Change-Id: I150b4fb48e9dc4cc34466ef6417c04ac93d4bc1a
Reviewed-on: https://go-review.googlesource.com/43970
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Current code uses names like "x" and "s" which can conflict with user's
code easily. Use cryptographic names.
Fixes#21668
Change-Id: Ib6d3d6327aa5b92d95c71503d42e3a79d96c8e15
Reviewed-on: https://go-review.googlesource.com/59710
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts commit a6ffab6b67.
Reason for revert: with CL 57290 the tests run on Android again.
Change-Id: Ifeb29762a4cd0178463acfeeb3696884d99d2993
Reviewed-on: https://go-review.googlesource.com/57310
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The testcshared test.bash was rewritten in Go, but the rewritten script
broke on Android. Make the tests run on Android again by:
- Restoring the LD_LIBRARY_PATH path (.).
- Restoring the Android specific C flags (-pie -fuse-ld=gold).
- Adding runExe to run test executables. All other commands must run on
the host.
Fixes#21513.
Change-Id: I3ea617a943c686b15437cc5c118e9802a913d93a
Reviewed-on: https://go-review.googlesource.com/57290
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Hopefully this will fix android build.
Maybe fixes#21513
Change-Id: I98f760562646f06b56e385c36927e79458465b92
Reviewed-on: https://go-review.googlesource.com/56790
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Another attempt to fix build
Change-Id: I26137c115ad4b5f5a69801ed981c146adf6e824c
Reviewed-on: https://go-review.googlesource.com/56750
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Hopefully fixes build.
Change-Id: If0629b95b923a65e4507073cf7aa44a5e178fc0f
Reviewed-on: https://go-review.googlesource.com/56711
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
