[ld-new] gold patch committed: Handle LDO_32 following LDM

[Cary Coutant]

> On i386, the R_386_TLS_LDO_32 relocation is handled in two different
> ways, depending upon whether it is being applied to an instruction or
> to debugging information.  Gold makes that determination based on
> whether it has seen a R_386_TLS_LDM reloc in the same section.
> Unfortunately, in some cases, instruction scheduling can cause the
> LDO_32 relocation to precede the LDM relocation.  In that case, gold
> will make the wrong decision.

Ugh. Guess it's too late to fix the ABI to use a different relocation.

> I committed this patch to fix the problem by keeping track of each
> LDO_32 relocation processed for the section.  If an LDM relocation is
> seen, the linker goes back and adjusts the preceding LDO_32
> relocations.
>
> The GNU linker makes this decision based on whether the section is
> executable or not.  That information is not readily available for
> gold.

But output_section->flags() is readily available in
Relocate::relocate() -- wouldn't that do?  Why not just pass
output_section -- or (output_section->flags() & elfcpp::SHF_EXECINSTR)
-- to relocate_tls()?

-cary