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

[Ian Lance Taylor]

Cary Coutant <ccoutant@google.com> writes:

>> 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.

Yeah, I guess so.  It does seem kind of dumb.


>> 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()?

What matters is not the flags of the output section, but the flags of
the input section.  That is, I'm concerned about crazy people using
linker scripts.  It wouldn't actually be that hard to pass the flags
down from Sized_relobj::relocate_sections, perhaps stuffing them in
Relocate_info.  Do you think it's worth it?

Ian