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

[Ian Lance Taylor]

Cary Coutant <ccoutant@google.com> writes:

>>> 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?
>
> Yes, I think adding the flags to Relocate_info would be much cleaner.
> (I don't have much sympathy, though, for anyone who puts an executable
> input section into a non-executable output section, but I guess we
> should support that.)

I committed this plan as follows.

Ian


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

	* object.h (class Relocate_info): Add reloc_shdr and data_shdr
	fields.
	* object.cc (Sized_relobj::relocate_sections): Set reloc_shdr and
	data_shdr fields of relinfo.
	* i386.cc (class Target_i386::Relocate): Remove ldo_addrs_ field.
	(Target_i386::Relocate::relocate_tls): Don't call fix_up_ldo.  For
	R_386_TLS_LDO_32, adjust based on section flags.
	(Target_i386::Relocate::fix_up_ldo): Remove.


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