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

[Rafael Espíndola via llvm-commits]

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