code review 7629043: cmd/ld: external linking fixes for linux/386

cmd/ld: external linking fixes for linux/386

The sticking point on 386 has been the "PC relative" relocations
used to point the garbage collection metadata at the type info.
These aren't in the code segment, and I don't trust that the linker
isn't doing something special that would be okay in code but
not when interpreting the pointers as data (for example, a PLT
jump table would be terrible).

Solve the problem in two steps:

1. Handle "PC relative" relocations within a section internally,
so that the external linker never sees them.

2. Move the gcdata and gcbss tables into the rodata section,
where the type information lives, so that the relocations can
be handled internally.

(To answer the obvious question, we make the gc->type
references relative so that they need not be relocated
individually when generating a shared object file.)

[rsc, 2013-03-08 06:28:33]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg

[rsc, 2013-03-08 18:48:33]

+iant

[iant, 2013-03-08 22:44:45]

PLT table construction is controlled by the type of the symbol.  You can get a
PLT entry for an STT_FUNC symbol, but not for an STT_OBJECT symbol.

[iant, 2013-03-08 22:48:12]

LGTM

[rsc, 2013-03-09 04:22:41]

*** Submitted as https://code.google.com/p/go/source/detail?r=01c40d533367 ***

cmd/ld: external linking fixes for linux/386

The sticking point on 386 has been the "PC relative" relocations
used to point the garbage collection metadata at the type info.
These aren't in the code segment, and I don't trust that the linker
isn't doing something special that would be okay in code but
not when interpreting the pointers as data (for example, a PLT
jump table would be terrible).

Solve the problem in two steps:

1. Handle "PC relative" relocations within a section internally,
so that the external linker never sees them.

2. Move the gcdata and gcbss tables into the rodata section,
where the type information lives, so that the relocations can
be handled internally.

(To answer the obvious question, we make the gc->type
references relative so that they need not be relocated
individually when generating a shared object file.)

R=golang-dev, iant
CC=golang-dev
https://codereview.appspot.com/7629043