This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [ld-new] gold patch committed: Handle LDO_32 following LDM
- From: Cary Coutant <ccoutant at google dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 6 Oct 2009 17:23:38 -0700
- Subject: Re: [ld-new] gold patch committed: Handle LDO_32 following LDM
- References: <mcreipg9p78.fsf@dhcp-172-17-9-151.mtv.corp.google.com>
> 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