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

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 26 18:14:12 PDT 2016


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





More information about the llvm-commits mailing list