<div dir="ltr">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.<div><br></div><div>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.)</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 6:14 PM, Peter Smith <span dir="ltr"><<a href="mailto:peter.smith@linaro.org" target="_blank">peter.smith@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">peter.smith added a comment.<br>
<br>
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.<br>
<br>
In summary:<br>
<br>
- 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.<br>
- 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.<br>
  - Just taking off the SHF_LINK_ORDER flag and clearing the sh_link field causes a warning from ld.bfd<br>
  - Discarding the .ARM.exidx sections and any associated relocations does work, although it does need some extra code in InputFiles to do this.<br>
<br>
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.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D24728" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D24728</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>