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

[Rui Ueyama via llvm-commits]

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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160926/6efd7f24/attachment.html>