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

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 7 18:51:23 PDT 2016


I agree that we should produce compatible object files for relocatable
outputs. So, as you wrote, we need to keep the original SHF_LINK_ORDER
relations with the target executable sections.

The problem with D24277 <https://reviews.llvm.org/D24277> approach
regarding relocatable output would be that, when multiple .text sections
are merged into one .text section, we need to merge .ARM.exidx sections as
instructed by SHF_LINK_ORDER and then create one SHF_LINK_ORDER to point to
the .text section. That means we would have to interpret SHF_LINK_ORDER for
relocatable output.

Here's what I'm thinking: we don't have to merge sections for relocatable
output at all. We can pass through all input sections to output with the
same names without merging them, and let the final linking merge them.

In that way, I think we don't need to interpret SHF_LINK_ORDER ourselves,
but instead just propagate SHF_LINK_ORDER.

Do you think this may work?

On Wed, Sep 7, 2016 at 4:07 AM, Peter Smith <peter.smith at linaro.org> wrote:

> peter.smith added a comment.
>
> 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.
>
>
> https://reviews.llvm.org/D24258
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160907/3f75c4ae/attachment.html>


More information about the llvm-commits mailing list