[PATCH] D24728: [ARM][LLD] Add support for .ARM.exidx sections

[Rafael Espíndola via llvm-commits]

I am getting a test failure:

// CHECK-SCRIPT-NEXT: 114: 1e ff 2f e1 bx lr

Cheers,
Rafael


On 27 September 2016 at 13:40, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 27 September 2016 at 12:48, Peter Smith <peter.smith at linaro.org> wrote:
>> Thanks for the feedback, unfortunately I'm struggling to find another
>> way that doesn't break the ABI. For better or worse the ARM ABI chose
>> to use SHF_LINK_ORDER so its what I have to work with, and is the only
>> thing I can assume that other linker's have implemented.
>>
>> The general problem I have is that the output of a relocatable link
>> can be fed into other links on any ABI compatible linker with the
>> final combination of .ARM.exidx sections in the final exe/so making
>> sense whichever linker does the final link. To be compatible with
>> other linkers such as ld.bfd and ld.gold two conditions have to hold:
>> 1.) Any .ARM.exidx Output Section needs to have a SHF_LINK_ORDER flag
>> set and a sh_link to the executable section it describes
>> 2.) Regardless of what order the linker combines the sections in the
>> final link, when all .ARM.exidx sections are combined into one section
>> they are in the correct order.
>>
>> The only things that I can think of that satisfies the second constraint are:
>> - Do not combine any .ARM.exidx input section or any section that a
>> .ARM.exidx section has a sh_link to.
>> - For each output section S, combine the .ARM.exidx sections that have
>> sh_links to input sections in S into a single output section.
>>
>> Combining all the .ARM.exidx sections into a single output section and
>> sorting it won't work in all cases. A final link that consumes the
>> relocatable object can change the order of any pair of sections,
>> breaking the sorting done for the relocatable object, and as we can't
>> guarantee that the final linker will resort the table the final output
>> could be incorrect.
>>
>> On the assumption that we want to keep the output of ld -r ABI
>> compatible we will need to produce a relocatable output file that
>> another linker can use SHF_LINK_ORDER to process. It is true that
>> internally to lld we don't need to use the SHF_LINK_ORDER to mechanism
>> to do this, we just need to put it in at the end.
>>
>> The most difficult part is to create the correct number of .ARM.exidx
>> output sections in the output. Adding the SHF_LINK_ORDER and sh_info
>> is relatively simple. There are a number of possible implementations:
>> 1.) The no combination option as implemented by D24728, using a flag
>> to say don't combine.
>> 2.) Use the naming convention of .ARM.exidx.section_name to construct
>> the OutputSections (can sort these as per the final link)
>> 3.) Do an ARM specific renaming pass of input sections such that
>> createOutputSection does the right thing.
>> 4.) Separate all .ARM.exidx sections from the input sections and do a
>> separate ARM specific createOutputSection pass to create the
>> OutputSections.
>>
>> Do you have any thoughts or preferences? I'm a bit stuck right now as
>> I can't change the ABI, and I can't see a way of writing the output
>> file in such a way that another linker will be guaranteed to do the
>> right thing.
>>
>> Peter
>>
>> P.S.
>> If you are vaguely interested, the ARM ABI has a design principle of
>> smart format dumb linker. In practical terms all decisions a linker
>> needs to make for a correct (if not optimal) output are explicit in
>> the ELF metadata. Requiring linkers to sort the exception tables would
>> have broken that principle. I also suspect that the exception table
>> design was heavily influenced by the Itanium ABI which also has
>> exception tables that are ordered using SHF_LINK_ORDER.
>
> Given the hack that .eh_frame is, that seems the correct design choice.
>
> I will take a look at the patch itself, but I think two options should
> have a fairly clean implementation:
>
> * Don't merge sections that is pointed by a SHF_LINK_ORDER section.
> * Assume that the merging is compatible. That is, that if a group of
> SHF_LINK_ORDER sections is merged, the sections they point to are also
> merged. I case where that doesn't happen (because of an odd linker
> script) is considered garbage in, garbage out.
>
> Cheers,
> Rafael