cmd/ld: invoke host linker for Windows cgo build

[rsc]

It should be possible to invoke the host linker for a cgo build.
That is, we'd run 6l to write a .o file for the Go pieces and then invoke gcc to do the
final link with the .syso files. This would fix many corner cases in 6l's support for
linking arbitrary ELF objects into the binary.

I would like to keep 6l's arbitrary ELF support so that one need not have a C compiler
installed to use a Go compiler, but we need the 'invoke gcc' plan as a fallback.

6l = 6l, 5l, 8l here, to avoid confusion with host ld.

[rsc]

Comment 1:

Issue #3591 has been merged into this issue.

[rsc]

Comment 8:

Labels changed: added size-l.

[rsc]

Comment 9:

Labels changed: added size-xl.

[rsc]

Comment 10:

Labels changed: removed size-l.

[rsc]

Comment 12:

Issue #4272 has been merged into this issue.

[rsc]

Comment 13:

Issue #1781 has been merged into this issue.

[rsc]

Comment 14:

Issue #3141 has been merged into this issue.

[rsc]

Comment 15:

Issue #3755 has been merged into this issue.

[rsc]

Comment 16:

An update: the beginning of this is implemented for darwin, linux, and *bsd on amd64 and
386. You can play by invoking the go build of a command with -ldflags=-hostobj but if it
breaks you get to keep both pieces.
Dwarf information is not correct, so you might need -ldflags='-w -hostobj' depending on
how paranoid the system linker is.
Windows has not been attempted yet.
ARM has not been attempted yet.
There is a real possibility that ARM and Windows will be skipped for this go-round.

[minux]

Comment 17:

how much remains to be done for cmd/5l?

[rsc]

Comment 18:

It's unclear to me how much is left in cmd/5l. The 6l and 8l linkers already had a
concept of a relocation and recorded the places that needed to be relocated, as part of
the standard linking, so that individual functions could be laid out separately and put
together only at the end. Adjusting them to emit the not-applied relocations was fairly
straightforward. 
5l does not have that flexibility: it lays out the entire code segment at once, because
I never changed it like I did 6l and 8l. So the required changes are more spread out
than in 6l/8l. Any part of the code layout in asm.c that uses ->pc or ->value is
suspect. However, the simplicity of the ARM instruction set might make it easier to find
these.
At the least, the two 'TODO: Use addrel' comments need to do that, although the one for
UNDEF could be changed into two instructions instead (MOVW $0, R0; BL R0). Also any case
listed in the table for C_SBRA or C_ADDR arguments, so cases 5, 11, 63, 64, 65, 68, 69,
74, 93, 94. It could be that most of the work is in addpool. It's all very unclear to me.

[rsc]

Comment 19:

Issue #4782 has been merged into this issue.

[eliasnaur]

Comment 20:

What is the plan for the ELF TLS sections? I have a test here that verifies whether
__thread variables work in foreign code:
https://golang.org/cl/7578043/
It currently crashes, presumably because TLS sections are missing from the -hostobj
generated executable.

[ianlancetaylor]

Comment 21:

As far as I can see, the gc ld is going to have to create a SHT_TLS section and
appropriate TLS relocations.  I don't really see a way around that.

[eliasnaur]

Comment 22:

Does that imply the relatively expensive call to __tls_get_addr in every stack size
prelude in many functions? I was hacking on support for generating .so files from Go,
but got stuck on this expensive need.