This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD][PATCH] Set SHF_LINK_ORDER flags of ARM EXIDX sections.
"Doug Kwan (éæå)" <dougkwan@google.com> writes:
> Gold does not handle SHF_LINK_ORDER flag in general, we drop the flag
> when searching for an output section.
>
> Output_section*
> Layout::choose_output_section(const Relobj* relobj, const char* name,
> elfcpp::Elf_Word type, elfcpp::Elf_Xword flags,
> bool is_input_section, Output_section_order order,
> bool is_relro)
> ...
>
> // Some flags in the input section should not be automatically
> // copied to the output section.
> flags &= ~ (elfcpp::SHF_INFO_LINK
> | elfcpp::SHF_LINK_ORDER
> | elfcpp::SHF_GROUP
> | elfcpp::SHF_MERGE
Oh yeah, sorry about that.
That is incorrect when generating relocatable output. Rather than
testing for SHT_ARM_EXIDX in the target-independent code, suppose we add
another bit flag to Output_section. Then we can set it if
SHF_LINK_ORDER is set in the input section, which will be correct once
we finally support SHF_LINK_ORDER. And the ARM backend can set it at
will.
Ian
> å 2010å10æ19æäå10:07ïIan Lance Taylor <iant@google.com> åéï
>> "Doug Kwan (éæå)" <dougkwan@google.com> writes:
>>
>>> This patch changes code writing output section headers so that the
>>> SHF_LINK_ORDER flag of a section of type SHT_ARM_EXIDX is always set.
>>> The flag is required to be set for such a section by the ARM EHABI.
>>> The existing code drops the SHF_LINK_ORDER flag and that confuses
>>> other tools. Gold does not handle SHF_LINK_ORDER in general but the
>>> ARM back-end can handle the EXIDX sections.
>>>
>>> -Doug
>>>
>>>
>>> 2010-10-19 Doug Kwan <dougkwan@google.com>
>>>
>>> * output.cc(Output_section::write_header): Set SHF_LINK_ORDER flags of
>>> ARM EXIDX sections.
>>
>> I don't see the ARM backend actually creating any SHT_ARM_EXIDX
>> sections. So it seems to me that they are input sections. If the ABI
>> requires the input sections to have the SHF_LINK_ORDER flag set, then
>> that setting should carry through to the output section. Does that not
>> happen?
>>
>> Ian
>>