gold patch committed: Handle LDO_32 following LDM

[Ian Lance Taylor]

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.

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.

Ian


2009-10-06  Ian Lance Taylor  <iant@google.com>

	* i386.cc (class Target_i386::Relocate): Add ldo_addrs_ field.
	(Target_i386::Relocate::relocate_tls): Call fix_up_ldo before
	changing local_dynamic_type_ from LOCAL_DYNAMIC_NONE.  When
	handling R_386_TLS_LDO_32, if local_dynamic_type_ is NONE, push
	the address on ldo_addrs_.
	(Target_i386::Relocate::fix_up_ldo): New function.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.patch
Type: text/x-diff
Size: 3109 bytes
Desc: LDO_32
URL: <https://sourceware.org/pipermail/binutils/attachments/20091006/891e840b/attachment.bin>