Cherry Zhang 7799756a50 cmd/link: fix GC data reading from shared library (attempt 2) ... 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>		2020-07-01 14:41:56 +00:00
..
main	cmd/link: fix GC data reading from shared library (attempt 2)	2020-07-01 14:41:56 +00:00
p	cmd/link: fix GC data reading from shared library (attempt 2)	2020-07-01 14:41:56 +00:00