This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GOLD][PATCH] Set SHF_LINK_ORDER flags of ARM EXIDX sections.


Here is a new patch.  I changed the code in layout.cc so that
SHF_LINK_ORDER is not filter in a relocatable link.  I also added a
check in the ARM back-end to warn about EXIDX input sections without
SHF_LINK_ORDER flags.

-Doug

2010-10-20  Doug Kwan  <dougkwan@google.com>

        * arm.cc (Arm_relobj::do_read_symbols): Warn about ARM EXIDX sections
        without SHF_LINK_ORDER flags.
        * layout.cc (Layout::choose_output_section): Do not filter
        SHF_LINK_ORDER flag in a relocatable link.


在 2010年10月20日上午8:41,Doug Kwan (關振德) <dougkwan@google.com> 寫道:
> I will try your approach.
>
> On Oct 20, 2010 3:39 AM, "Cary Coutant" <ccoutant@google.com> wrote:
>> I'm not wild about this patch. I think it would be better to just refuse
>> to
>> combine sections with unlike flags in a -r link -- ie, don't filter out so
>> many of the flags. I'm not near the code at the moment, but I don't think
>> any target-specific magic is necessary here.
>>
>> -cary
>> On Oct 19, 2010 11:54 AM, "Doug Kwan (關振德)" <dougkwan@google.com> wrote:
>>> Here is a revised patch.
>>>
>>> -Doug
>>>
>>> 2010-10-19 Doug Kwan <dougkwan@google.com>
>>>
>>> * arm.cc (Target_arm::do_finalize_sections): Force SHF_LINK_ORDER
>>> flag in section headers of EXIDX sections in a relocatable link.
>>> * output.cc (Output_section::Output_section): Initialize member
>>> force_link_order_.
>>> * output.h (Output_section::force_link_order): New method.
>>> (Output_section::set_force_link_order): Ditto.
>>> (Output_section::force_link_order_): New data member.
>>>
>>>
>>> 在 2010年10月20日上午12:53,Ian Lance Taylor <iant@google.com> 寫道:
>>>> "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
>>>>>>
>>>>
>

Attachment: patch-no-filter.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]