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

Tue Sep 27 12:48:07 PDT 2016

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.

On 26 September 2016 at 18:51, Rui Ueyama <ruiu at google.com> wrote:
> I totally agree that we should support relocatable link for ARM. We support
> it for all the other architectures and ARM shouldn't be an exception; they
> should be treated equal.
>
> But at the same time, I can't stop thinking that the mechanism to sort
> .ARM.exidx contents is a product of over-generalization. SHF_LINK_ORDER is a
> generic feature that is sometimes tricky particularly when combined with
> linker scripts. If the ABI just defined that the linker needed to sort the
> .ARM.exidx, it would have been much easier to handle. So I'm not still
> comfortable with supporting SHF_LINK_ORDER (but I could be convinced the
> other way if doing so turns out to make sense.)
>
> I'm wondering if we can create a SHF_LINK_ORDER for relocatable output. I
> mean, if we sort .ARM.exidx contents and create a SHF_LINK_ORDER to a
> relocatable output, then the resulting relocatable output is compatible in
> terms of the ARM ABI? I'm not suggesting to do that way (yet), but I'm
> wondering what would be the best way to support relocatable output for ARM.
>
> On Mon, Sep 26, 2016 at 6:14 PM, Peter Smith <peter.smith at linaro.org> wrote:
>>
>> peter.smith added a comment.
>>
>> I've done some experiments to split out the relocatable links from the
>> application and whilst it does simplify the patch it does have some
>> complications surrounding what to do with .ARM.exidx sections during a
>> relocatable link. In particular it is quite difficult to give a useful
>> warning that .ARM.exidx sections aren't supported.
>>
>> In summary:
>>
>> - Clang will output a .cantunwind .ARM.exidx table even for C code
>> compiled without exceptions. If we were to give a warning that .ARM.exidx
>> wasn't supported for relocatable links it would be given for every
>> relocatable link even if the .ARM.exidx sections were never used. It could
>> be possible to scan the .ARM.exidx sections and assume that if all of the
>> entries were .cantunwind then no warning is needed, however this is starting
>> to put the complexity back in.
>> - We can't completely ignore .ARM.exidx sections as the combined output
>> .ARM.exidx will have the SHF_LINK_ORDER flag and an incorrect sh_link field.
>> This is likely to cause problems if the object is used in a subsequent link.
>>   - Just taking off the SHF_LINK_ORDER flag and clearing the sh_link field
>> causes a warning from ld.bfd
>>   - Discarding the .ARM.exidx sections and any associated relocations does
>> work, although it does need some extra code in InputFiles to do this.
>>
>> My preference would be to implement support for relocatable objects. Given
>> that there aren't many serious users of lld for ARM I think it would be
>> possible for a short time to split out the relocatable alterations with lld
>> discarding all .ARM.exidx sections in a relocatable link, but I think it
>> would need fixing rather than leaving it unsupported.
>>
>>
>> https://reviews.llvm.org/D24728
>>
>>
>>
>