summaryrefslogtreecommitdiff
path: root/misc/cgo/testshared
Commit message (Collapse)AuthorAgeFilesLines
* all: update references to symbols moved from io/ioutil to ioKimMachineGun2021-04-051-7/+6
| | | | | | | | | | | | | | | Update references missed in CL 263142. For #41190 Change-Id: I778760a6a69bd0440fec0848bdef539c9ccb4ee1 GitHub-Last-Rev: dda42b09fff36dc08ec1cdec50cc19e3da5058e5 GitHub-Pull-Request: golang/go#42874 Reviewed-on: https://go-review.googlesource.com/c/go/+/273946 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Cherry Zhang <cherryyz@google.com>
* all: use more precise build tagsTamir Duberstein2021-02-232-2/+2
| | | | | | | | | | s/!gccgo/gc/ in files which use gc-syntax assembly. Change-Id: Ifdadb62edd1210ebc70e7cd415648b752afaf067 Reviewed-on: https://go-review.googlesource.com/c/go/+/269957 Reviewed-by: Than McIntosh <thanm@google.com> Trust: David Chase <drchase@google.com> Trust: Matthew Dempsky <mdempsky@google.com>
* cmd/link: don't decode type symbol in shared library in deadcodeCherry Zhang2021-02-024-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the linker's deadcode pass we decode type symbols for interface satisfaction analysis. When linking against Go shared libraries, the type symbol may come from a shared library, so it doesn't have data in the current module being linked, so we cannot decode it. We already have code to skip DYNIMPORT symbols. However, this doesn't actually work, because at that point the type symbols' names haven't been mangled, whereas they may be mangled in the shared library. So the symbol definition (in shared library) and reference (in current module) haven't been connected. Skip decoding type symbols of type Sxxx (along with DYNIMPORT) when linkShared. Note: we cannot skip all type symbols, as we still need to mark unexported methods defined in the current module. Fixes #44031. Change-Id: I833d19a060c94edbd6fc448172358f9a7d760657 Reviewed-on: https://go-review.googlesource.com/c/go/+/288496 Trust: Cherry Zhang <cherryyz@google.com> Trust: Than McIntosh <thanm@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
* cmd/link: don't mark shared library symbols reachable unconditionallyCherry Zhang2020-07-271-0/+13
| | | | | | | | | | | | | | | | | | | | During the transitioning period, we mark symbols from Go shared libraries reachable unconditionally. That might be useful when there was still a large portion of the linker using sym.Symbols, and only reachable symbols were converted to sym.Symbols. Marking them reachable brings them to the dynamic symbol table, even if they are not needed, increased the binary size unexpectedly. That time has passed. Now we largely operate on loader symbols, and it is not needed to mark them reachable anymore. Fixes #40416. Change-Id: I1e2bdb93a960ba7dc96575fabe15af93d8e95329 Reviewed-on: https://go-review.googlesource.com/c/go/+/244839 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/link: fix GC data reading from shared library (attempt 2)Cherry Zhang2020-07-013-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When linking against a Go shared library, when a global variable in the main module has a type defined in the shared library, the linker needs to pull the GC data from the shared library to build the GC program for the global variable. Currently, this fails silently, as the shared library file is closed too early and the read failed (with no error check), causing a zero GC map emitted for the variable, which in turn causes the runtime to treat the variable as pointerless. For now, fix this by keeping the file open. In the future we may want to use mmap to read from the shared library instead. Also add error checking. And fix a (mostly harmless) mistake in size caluculation. Also remove an erroneous condition for ARM64. ARM64 used to have a special case to get the addend from the relocation on the gcdata field. That was removed, but the new code accidentally returned 0 unconditionally. It's no longer necessary to have any special case, since the addend is now applied directly to the gcdata field on ARM64, like on all the other platforms. Fixes #39927. This is the second attempt of CL 240462. And this reverts CL 240616. Change-Id: I01c82422b9f67e872d833336885935bc509bc91b Reviewed-on: https://go-review.googlesource.com/c/go/+/240621 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
* Revert "cmd/link: fix GC data reading from shared library"Cherry Zhang2020-06-303-60/+0
| | | | | | | | | | | | | This reverts CL 240462. Reason for revert: test fails on PPC64LE. Updates #39927. Change-Id: I4f14fd0c36e604a80ae9f2f86d1e643e28945e93 Reviewed-on: https://go-review.googlesource.com/c/go/+/240616 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
* cmd/link: fix GC data reading from shared libraryCherry Zhang2020-06-303-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When linking against a Go shared library, when a global variable in the main module has a type defined in the shared library, the linker needs to pull the GC data from the shared library to build the GC program for the global variable. Currently, this fails silently, as the shared library file is closed too early and the read failed (with no error check), causing a zero GC map emitted for the variable, which in turn causes the runtime to treat the variable as pointerless. For now, fix this by keeping the file open. In the future we may want to use mmap to read from the shared library instead. Also add error checking. And fix a (mostly harmless) mistake in size caluculation. Also remove an erroneous condition for ARM64. ARM64 used to have a special case to get the addend from the relocation on the gcdata field. That was removed, but the new code accidentally returned 0 unconditionally. It's no longer necessary to have any special case, since the addend is now applied directly to the gcdata field on ARM64, like on all the other platforms. Fixes #39927. Change-Id: Iecd32315b326c7059587fdc190e2fa99426e497e Reviewed-on: https://go-review.googlesource.com/c/go/+/240462 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Austin Clements <austin@google.com>
* cmd/link: skip zero values in fingerprint checkCherry Zhang2020-06-233-0/+22
| | | | | | | | | | | | | | | | | | Normally, packages are loaded in dependency order, and if a Library object is not nil, it is already loaded with the actual fingerprint. In shared build mode, however, packages may be added not in dependency order (e.g. go install -buildmode=shared std adds all std packages before loading them), and it is possible that a Library's fingerprint is not yet loaded. Skip the check in this case (when the fingerprint is the zero value). Fixes #39777. Change-Id: I66208e92bf687c8778963ba8e33e9bd948f82f3a Reviewed-on: https://go-review.googlesource.com/c/go/+/239517 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
* test: fix -test.v trace output for cgo/testsharedThan McIntosh2020-03-201-1/+1
| | | | | | | | | | | | Trace output showing how dummy GOROOT was being set up was incorrect (sense of the "cp -r" trace messages was inverted). This patch fixes the problem. Change-Id: Ib0ee649e305bfa1bc0c49e0d5ba2ea31e0a4f67e Reviewed-on: https://go-review.googlesource.com/c/go/+/224377 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
* misc/cgo/testshared: explicitly set GOBIN (instead of unsetting it)Bryan C. Mills2020-02-241-4/+2
| | | | | | | | | | | | | | | If GOBIN is set in the GOENV file, then merely unsetting it in the process environment is not sufficient. We can instead either set GOBIN explicitly, or disable GOENV explicitly. For now, we (semi-arbitrary) choose the former. Fixes #37390 Change-Id: Iec54532c804b70546d695105cd89e9169eac5dbb Reviewed-on: https://go-review.googlesource.com/c/go/+/220652 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* misc/cgo/testshared: do not write to GOROOTBryan C. Mills2019-11-251-49/+127
| | | | | | | | | | | | | | | | | | | Instead of installing shared libraries to GOROOT/pkg, clone the necessary files into a new GOROOT and run there. Given that we now have a build cache, ideally we should not need to install into GOROOT/pkg at all, but we can't fix that during the 1.14 code freeze. Updates #28387 Updates #28553 Updates #30316 Change-Id: I83084a8ca29a5dffcd586c7fccc3f172cac57cc6 Reviewed-on: https://go-review.googlesource.com/c/go/+/208482 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
* misc: remove use of relative directories in overlayDir functionsBryan C. Mills2019-11-251-7/+4
| | | | | | | | | | | | | | | | | | | | | | It turns out that the relative-path support never worked in the first place. It had been masked by the fact that we ~never invoke overlayDir with an absolute path, which caused filepath.Rel to always return an error, and overlayDir to always fall back to absolute paths. Since the absolute paths seem to be working fine (and are simpler), let's stick with those. As far as I can recall, the relative paths were only a space optimization anyway. Updates #28387 Updates #30316 Change-Id: Ie8cd28f3c41ca6497ace2799f4193d7f5dde7a37 Reviewed-on: https://go-review.googlesource.com/c/go/+/208481 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
* misc/cgo/testshared: make -v output less verboseBryan C. Mills2019-11-221-10/+14
| | | | | | | | | | | | | | | Previously, 'go test -v' in this directory would result in a massive dump of go command output, because the test plumbed -v to 'build -x'. This change separates them into distinct flags, so that '-v' only implies the display of default 'go' command output. Updates #30316 Change-Id: Ifb125f35ec6a0bebe7e8286e7c546d132fb213df Reviewed-on: https://go-review.googlesource.com/c/go/+/208232 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* misc: ensure that test overlay directories are writableBryan C. Mills2019-11-111-1/+1
| | | | | | | | | | | | | Otherwise, the test cannot create new files in the directory. Updates #32407 Updates #30316 Change-Id: Ief0df94a202be92f57d458d4ab4e4daa9ec189b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/206458 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* cmd/link: put shlib ".type" functions in internal ABIIan Lance Taylor2019-07-153-0/+40
| | | | | | | | | | | | | | These functions are compiler generated, and as such are only available in the internal ABI. Doing this avoids generating an alias symbol. Doing that avoids confusion between unmangled and mangled type symbols. Fixes #30768 Change-Id: I197a5ba6403aac11989ffa951dbe35bd0506de91 Reviewed-on: https://go-review.googlesource.com/c/go/+/186077 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* misc/cgo: gofmt testdata filesTobias Klauser2019-03-221-1/+2
| | | | | | | | Change-Id: I64e05a1f768cb57194506021bb7fdca0ad19bf1c Reviewed-on: https://go-review.googlesource.com/c/go/+/168461 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* misc/cgo: skip cgotest.TestCrossPackageTests on iOS and set PWDBryan C. Mills2019-02-261-0/+1
| | | | | | | | | | | | | | | 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>
* misc/cgo/testshared: fix tests in module modeBryan C. Mills2019-02-2224-172/+276
| | | | | | | | | Updates #30228 Change-Id: I5cc739eb9fdfb648ec45e350d43d4cb02e450553 Reviewed-on: https://go-review.googlesource.com/c/163211 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
* cmd/compile: emit a symbol for a method expression when using -dynlinkIan Lance Taylor2018-12-112-0/+26
| | | | | | | | Fixes #25065 Change-Id: Ia3db518cfd9c006caf951b51342a491ac8372e9c Reviewed-on: https://go-review.googlesource.com/c/153297 Reviewed-by: Robert Griesemer <gri@golang.org>
* all: fix a bunch of misspellingsIgor Zhilianin2018-10-061-1/+1
| | | | | | | | | | Change-Id: If2954bdfc551515403706b2cd0dde94e45936e08 GitHub-Last-Rev: d4cfc41a5504cf10befefdb881d4c45986a1d1f8 GitHub-Pull-Request: golang/go#28049 Reviewed-on: https://go-review.googlesource.com/c/140299 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* all: fix typos detected by github.com/client9/misspellKazuhiro Sera2018-08-231-1/+1
| | | | | | | | | | Change-Id: Iadb3c5de8ae9ea45855013997ed70f7929a88661 GitHub-Last-Rev: ae85bcf82be8fee533e2b9901c6133921382c70a GitHub-Pull-Request: golang/go#26920 Reviewed-on: https://go-review.googlesource.com/128955 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/go: fix handling of vet.cfg with buggyInstallIan Lance Taylor2018-07-171-0/+6
| | | | | | | | | | | | | | | | | The vet action assumes that a.Deps[0] is the compilation action for which vet information should be generated. However, when using -linkshared, the action graph is built with a ModeBuggyInstall action to install the shared library built from the compilation action. Adjust the set up of the vet action accordingly. Also don't clean up the working directory after completing the buggy install. Updates #26400 Change-Id: Ia51f9f6b8cde5614a6f2e41b6207478951547770 Reviewed-on: https://go-review.googlesource.com/124275 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
* testshared/src/depBase: conform build tag comment to conventionDan Kortschak2018-07-064-3/+15
| | | | | | | | | | | Also add missing copyright headers with year determined from git log. Change-Id: Iafc9881e746543f0a582dad2b0874d8399baf618 Reviewed-on: https://go-review.googlesource.com/122415 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/link: never coalesce type descriptors when dynamically linking GoMichael Hudson-Doyle2018-06-231-0/+5
| | | | | | | | | | | | | 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>
* cmd/go: fix go list .Stale computationRuss Cox2018-04-251-0/+1
| | | | | | | | | | | | | | | | | 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>
* cmd/go: make gccgo -buildmode=shared and -linkshared work againIan Lance Taylor2018-01-121-4/+1
| | | | | | | | | | | | | | | | | | | | 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>
* all: change github.com issue links to golang.orgLeigh McCulloch2017-11-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/go: run vet automatically during go testRuss Cox2017-11-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/go: switch to entirely content-based staleness determinationRuss Cox2017-10-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* misc/cgo/testshared: don't assume mtimes trigger rebuildsRuss Cox2017-10-301-25/+78
| | | | | | | | | | | 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>
* misc/cgo/testshared: disable TestTwoGopathShlibsGccgoRuss Cox2017-10-281-0/+2
| | | | | | | | | | For #22224. Change-Id: Iae873fddc72a79a96a32eaeb5d4dd885eaf810cb Reviewed-on: https://go-review.googlesource.com/73851 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* cmd/go: clean up compile vs link vs shared library actionsRuss Cox2017-10-111-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* go/printer: fix formatting of three-index slice expressiongriesemer2017-10-031-1/+1
| | | | | | | | | | | | Apply gofmt to src, misc. Fixes #22111. Change-Id: Ib1bda0caaf2c1787a8137b7a61bbef7a341cc68c Reviewed-on: https://go-review.googlesource.com/67633 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
* cmd/go: use -importcfg to invoke compiler, linkerRuss Cox2017-09-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmd/compile: fix large global variables in -linkshared mode on s390xMichael Munday2017-09-203-0/+97
| | | | | | | | | | | | | | | | | | | | | | | 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>
* misc/cgo/testshared: call flag.Parse in TestMainHiroshi Ioka2017-08-151-0/+3
| | | | | | | | | | Otherwise, some test flags don't work. Change-Id: Iacf3930d0eec28e4d690cd382adbb2ecf866a0e2 Reviewed-on: https://go-review.googlesource.com/55615 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/link: only include the version info and export data in ABI hashMichael Hudson-Doyle2017-04-171-2/+10
| | | | | | | | | | | | | | | | Previously the "ABI hash" for a package (used to determine if a loaded shared library has the ABI expected by its loader) was the hash of the entire __.PKGDEF file. But that means it depends on the build ID generated by the go tool for the package, which means that if a file is added (even a .c or .h file!) to the package, the ABI changes, perhaps uncessarily. Fixes #19920 Change-Id: If919481e1a03afb350c8a9c7a0666bb90ee90270 Reviewed-on: https://go-review.googlesource.com/40401 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* runtime: use hardware divider to improve performanceBen Shi2017-04-112-0/+23
| | | | | | | | | | | | | | | | | | | | | The hardware divider is an optional component of ARMv7. This patch detects whether it is available in runtime and use it or not. 1. The hardware divider is detected at startup and a flag is set/clear according to a perticular bit of runtime.hwcap. 2. Each call of runtime.udiv will check this flag and decide if use the hardware division instruction. A rough test shows the performance improves 40-50% for ARMv7. And the compatibility of ARMv5/v6 is not broken. fixes #19118 Change-Id: Ic586bc9659ebc169553ca2004d2bdb721df823ac Reviewed-on: https://go-review.googlesource.com/37496 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
* misc/cgo/testshared: remove unused flag.Parse()Daniel Martí2017-02-021-2/+0
| | | | | | | | | | TestMain doesn't make use of any flags. Change-Id: I98ec582fb004045a5067618f605ccfeb1f9f4bbb Reviewed-on: https://go-review.googlesource.com/33613 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* runtime: reorder modules so main.main comes firstDavid Crawshaw2017-01-252-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Modules appear in the moduledata linked list in the order they are loaded by the dynamic loader, with one exception: the firstmoduledata itself the module that contains the runtime. This is not always the first module (when using -buildmode=shared, it is typically libstd.so, the second module). The order matters for typelinksinit, so we swap the first module with whatever module contains the main function. Updates #18729 This fixes the test case extracted with -linkshared, and now go test -linkshared encoding/... passes. However the original issue about a plugin failure is not yet fixed. Change-Id: I9f399ecc3518e22e6b0a350358e90b0baa44ac96 Reviewed-on: https://go-review.googlesource.com/35644 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* misc/cgo/testshared: test that types and itabs are uniqueKeith Randall2017-01-125-0/+79
| | | | | | | | | | | Make sure that the same type and itab generated in two different shared library are actually the same thing. Change-Id: Ica45862d65ff8bc7ad04d59a41f57223f71224cd Reviewed-on: https://go-review.googlesource.com/35115 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* cmd/compile, runtime: a different approach to duplicate itabsMichael Hudson-Doyle2016-12-191-0/+12
| | | | | | | | | | | | | | | | | | golang.org/issue/17594 was caused by additab being called more than once for an itab. golang.org/cl/32131 fixed that by making the itabs local symbols, but that in turn causes golang.org/issue/18252 because now there are now multiple itab symbols in a process for a given (type,interface) pair and different code paths can end up referring to different itabs which breaks lots of reflection stuff. So this makes itabs global again and just takes care to only call additab once for each itab. Fixes #18252 Change-Id: I781a193e2f8dd80af145a3a971f6a25537f633ea Reviewed-on: https://go-review.googlesource.com/34173 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
* cmd/link: do not mark go.plugin.tabs as reachable in non-pluginsMichael Hudson-Doyle2016-12-081-0/+5
| | | | | | | | | Fixes #18250 Change-Id: I4f61591356ddb4a906c206ad8456d1839daf7b91 Reviewed-on: https://go-review.googlesource.com/34170 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: David Crawshaw <crawshaw@golang.org>
* cmd/compile, runtime: make the go.itab.* symbols module-localMichael Hudson-Doyle2016-10-272-0/+15
| | | | | | | | | | | | | | | Otherwise, the way the ELF dynamic linker works means that you can end up with the same itab being passed to additab twice, leading to the itab linked list having a cycle in it. Add a test to additab in runtime to catch this when it happens, not some arbitrary and surprsing time later. Fixes #17594 Change-Id: I6c82edcc9ac88ac188d1185370242dc92f46b1ad Reviewed-on: https://go-review.googlesource.com/32131 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/link: fix -buildmode=pie / -linkshared combinationMichael Hudson-Doyle2016-09-131-0/+8
| | | | | | | | | | | | main.main and main.init were not being marked as reachable. Fixes #17076 Change-Id: Ib3e29bd35ba6252962e6ba89173ca321ed6849b9 Reviewed-on: https://go-review.googlesource.com/28996 Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* go/build: don't alter InstallSuffix for default compile optionsJosh Bleecher Snyder2016-08-261-2/+2
| | | | | | | | | | Fixes #16378. Change-Id: I99a064f1afec78fb63cb3719061d20be0f21d45d Reviewed-on: https://go-review.googlesource.com/24930 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* cmd/compile: ppc64le working, not optimized enoughDavid Chase2016-08-181-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | This time with the cherry-pick from the proper patch of the old CL. Stack size increased. Corrected NaN-comparison glitches. Marked g register as clobbered by calls. Fixed shared libraries. live_ssa.go still disabled because of differences. Presumably turning on more optimization will fix both the stack size and the live_ssa.go glitches. Enhanced debugging output for shared libs test. Rebased onto master. Updates #16010. Change-Id: I40864faf1ef32c118fb141b7ef8e854498e6b2c4 Reviewed-on: https://go-review.googlesource.com/27159 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
* cmd/internal/obj, runtime: fixes for defer in 386 shared librariesMichael Hudson-Doyle2016-06-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | Any defer in a shared object crashed when GOARCH=386. This turns out to be two bugs: 1) Calls to morestack were not processed to be PIC safe (must have been possible to trigger this another way too) 2) jmpdefer needs to rewind the return address of the deferred function past the instructions that load the GOT pointer into BX, not just past the call Bug 2) requires re-introducing the a way for .s files to know when they are being compiled for dynamic linking but I've tried to do that in as minimal a way as possible. Fixes #15916 Change-Id: Ia0d09b69ec272a176934176b8eaef5f3bfcacf04 Reviewed-on: https://go-review.googlesource.com/23623 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* cmd/compile: do not generate tail calls when dynamic linking on ppc64leMichael Hudson-Doyle2016-06-022-1/+6
| | | | | | | | | | | | | | | When a wrapper method calls the real implementation, it's not possible to use a tail call when dynamic linking on ppc64le. The bad scenario is when a local call is made to the wrapper: the wrapper will call the implementation, which might be in a different module and so set the TOC to the appropriate value for that module. But if it returns directly to the wrapper's caller, nothing will reset it to the correct value for that function. Change-Id: Icebf24c9a2a0a9a7c2bce6bd6f1358657284fb10 Reviewed-on: https://go-review.googlesource.com/23468 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* cmd/link: always read type data for dynimport symbolsMichael Hudson-Doyle2016-05-049-43/+88
| | | | | | | | | | | | | | | | | | | | | | | | | Consider three shared libraries: libBase.so -- defines a type T lib2.so -- references type T lib3.so -- also references type T, and something from lib2 lib2.so will contain a type symbol for T in its symbol table, but no definition. If, when linking lib3.so the linker reads the symbols from lib2.so before libBase.so, the linker didn't read the type data and later crashed. The fix is trivial but the test change is a bit messy because the order the linker reads the shared libraries in ends up depending on the order of the import statements in the file so I had to rename one of the test packages so that gofmt doesn't fix the test by accident... Fixes #15516 Change-Id: I124b058f782c900a3a54c15ed66a0d91d0cde5ce Reviewed-on: https://go-review.googlesource.com/22744 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
View Lorry Controller Status