summaryrefslogtreecommitdiff
path: root/misc/cgo/testshared/testdata
Commit message (Collapse)AuthorAgeFilesLines
* 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-023-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: fix GC data reading from shared library (attempt 2)Cherry Zhang2020-07-012-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-302-44/+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-302-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-232-0/+16
| | | | | | | | | | | | | | | | | | 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>
* cmd/link: put shlib ".type" functions in internal ABIIan Lance Taylor2019-07-152-0/+33
| | | | | | | | | | | | | | 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/testshared: fix tests in module modeBryan C. Mills2019-02-2222-0/+395
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>
View Lorry Controller Status