runtime, liblink, cmd/ld: externally linked binaries without cgo crash immediately on amd64

[mwhudson]

If you externally link a binary and runtime/cgo.a cannot be found (maybe by saying CGO_ENABLED=0 ./make.bash) you get a warning, and a binary that crashes during startup:

mwhudson@narsil:src$ ../bin/go run -ldflags -linkmode=external /opt/opensource/go-test-cases/trivial.go
# command-line-arguments
warning: unable to find runtime/cgo.a
signal: segmentation fault (core dumped)

The reason turns out to be a disagreement over the TLS offset for g. Presumably because both g and m used to be stored in TLS, the runtime and internal linking assumes it to be 16 but as g is now the only pointer stored in TLS, binutils ld sets it to 8, causing the tls consistency check on startup to fail.

I see two ways to fix this: one would be to just change the runtime and internal linker to assume the offset is 8 bytes and the other would be use a special relocation to get the linker (either internal or external) to tell us what the symbol is. In the latter case I don't think there would really be any need to do the magic import of runtime/cgo in an externally linked program (the comment justifying it is already a bit wrong, unless I am very confused).

[minux]

The reason external linked programs require runtime/cgo is that on certain OSes (notably Darwin), once the system libc runs, we can no longer create threads using syscalls due to conflicts (bsdthread_register).

[mwhudson]

Ah, so my evil plan to delete that code completely can't work. Shame. Maybe we can update the comment though?

[minux]

Sure.