This is an archive of the discontinued LLVM Phabricator instance.

[ARM][LLD] Add support for .ARM.exidx sections
AbandonedPublic

Authored by peter.smith on Sep 6 2016, 9:07 AM.

Details

Summary

This is a rewrite of the abandoned revision https://reviews.llvm.org/D24032 Add support for SHF_LINK_ORDER flag to ARM Target.

Instead of introducing SHF_LINK_ORDER as a general feature we just implement support for .ARM.exidx sections. This is done by creating a subclass of InputSectionBase and OutputSectionBase to handle the special case code.

I've taken the opportunity to add support for the PT_ARM_EXIDX program header as it is much simpler with this design. The PT_ARM_EXIDX program header is similar to the PT_GNU_EH_FRAME. This can easily be added as a separate patch, but it would mean updating the offsets in the test.

With .ARM.exidx support implemented all that should be needed for ARM exceptions support is to add support for the R_ARM_TARGET2 relocation, which should be straightforward.

References:
ARM exception handling ABI http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf
ELF for the ARM Architecture http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

Limitations that can be addressed in the future:

  • Garbage collection can be optimized with a similar special case to the .eh_frame section. A .ARM.exidx section should be live only when the executable section it links to is live.
  • Linker scripts assume that all InputSections assigned to an OutputSection are the same class. A contrived linker script such as

SECTIONS {

.text : { *(.text) *(.eh_frame*) }

}
Will give an internal fault rather than an error. This also affects .ARM.exidx sections mixed with regular OutputSections

  • Table compression is not implemented. The EHABI permits adjacent table entries to be folded if they have the same unwinding instructions. Compressing the table will alter the size of the OutputSection which can't be done safely in writeTo().

Diff Detail

Event Timeline

peter.smith updated this revision to Diff 70407.Sep 6 2016, 9:07 AM
peter.smith retitled this revision from to [ARM][LLD] Add support for .ARM.exidx sections.
peter.smith updated this object.
peter.smith added reviewers: ruiu, rafael, grimar.
peter.smith added subscribers: llvm-commits, rengolin.
ruiu edited edge metadata.Sep 6 2016, 1:22 PM

What I was trying to suggest is to completely ignore LINK_ORDER and instead sort section contents directly. In order to describe my idea, I created a change: https://reviews.llvm.org/D24277. It does not compile because it is for the sake of discussion. I'm not an ARM expert so it is likely that I'm missing something. Do you think this approach could work?

I think the approach in https://reviews.llvm.org/D24277 will work for executables, but it won't be sufficient to produce relocatable object files with SHF_LINK_ORDER dependencies.

I'll state what I think a linker has to do to support exceptions:

Garbage collection:
There are no relocations to any .ARM.exidx section so at a minimum they must be marked live.

Output Sections:
For a full link there must be one .ARM.exidx OutputSection containing all input .ARM.exidx sections with table entries in the same order as the functions described by the table entries.

For a relocatable link (ABI compliant) the output object must have an .ARM.exidx OutputSection for each executable OutputSection that has exeception tables. The .ARM.exidx OutputSection has SHF_LINK_ORDER and a sh_link field to the OutputSection. The table entries must be in the same order as the functions in the executable OutputSection

For a relocatable link (Consumable by lld only if it sorts the individual table entries) the output object must preserve the .ARM.exidx OutputSection name.

Program Headers
In an executable and shared object, the linker generates a PT_ARM_EXIDX program header that has the same address and size as the .ARM.exidx section.

The part that requires most of the code for SHF_LINK_ORDER is the ABI compliant relocatable object. If this is implemented then executables/shared objects drop out for free.

I could do another rewrite with a sorting of each individual entry rather than section. The actual table entry is not set up to do this easily although it is possible (see comment in https://reviews.llvm.org/D24277). With the small parts for garbage collection and PT_ARM_EXIDX that would give executable support, and relocatable support for lld, however the relocatable objects wouldn't be consumable by other linkers.

Personally I'd like maintain ABI compatibility so that relocatable output can be consumed by other linkers such as ld and gold. In theory it should be possible to use a similar approach to https://reviews.llvm.org/D24277 and set the sh_link field. I'm not sure it will be much simpler than what I have now or in the previous review though.

I'll be out of the office till next Monday, I'll pick up any comments when I'm back.

peter.smith abandoned this revision.Sep 19 2016, 8:19 AM

Abandoning this revision. I'll use a new review for the revised version.