cmd/internal/obj: fix LSym.Type during compilation, not linking
Prior to this CL, the compiler and assembler were sloppy about the LSym.Type for LSyms containing static data. The linker then fixed this up, converting Sxxx and SBSS to SDATA, and SNOPTRBSS to SNOPTRDATA if it noticed that the symbol had associated data. It is preferable to just get this right in cmd/compile and cmd/asm, because it removes an unnecessary traversal of the symbol table from the linker (see #14624). Do this by touching up the LSym.Type fixes in LSym.prepwrite and Link.Globl. I have confirmed by instrumenting the linker that the now-eliminated code paths were unreached. And an additional check in the object file writing code will help preserve that invariant. There was a case in the Windows linker, with internal linking and cgo, where we were generating SNOPTRBSS symbols with data. For now, convert those at the site at which they occur into SNOPTRDATA, just like they were. Does not pass toolstash-check, but does generate identical linked binaries. No compiler performance changes. Change-Id: I77b071ab103685ff8e042cee9abb864385488872 Reviewed-on: https://go-review.googlesource.com/40864 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Showing
Please
register
or
sign in
to comment