This is an archive of the discontinued LLVM Phabricator instance.

Handle ARM exception table.
Needs ReviewPublic

Authored by ruiu on Sep 6 2016, 1:16 PM.

Details

Reviewers
psmith
Summary

Handle ARM exception table.

Diff Detail

Event Timeline

ruiu updated this revision to Diff 70462.Sep 6 2016, 1:16 PM
ruiu retitled this revision from to Handle ARM exception table..
ruiu updated this object.
jmolloy added a subscriber: jmolloy.Sep 6 2016, 1:38 PM
jmolloy added inline comments.
ELF/Writer.cpp
1332

Is it possible to have duplicate / alias symbols here? If so, should this be a stable_sort?

ruiu added inline comments.Sep 6 2016, 1:43 PM
ELF/Writer.cpp
1332

I don't know about that. If there are alias symbols to a function, std::stable_sort is needed so that we'll get a reproducible output.

I think that this could work for executables/shared objects, and it would work for lld regardless of the order of the .ARM.exidx sections in the object provided they were collated correctly into one OutputSection.

To produce relocatable objects that are compatible with other linkers such as GNU ld and gold (which will expect SHF_LINK_ORDER), we would need to maintain the one .ARM.exidx OutputSection per executable OutputSection, maintain the order of the table entries in each .ARM.exidx OutputSection and maintain the link order dependency in the sh_link field. If we implement SHF_LINK_ORDER for relocatable objects then executables come for free.

I'll put a summarising comment in the original review.

ELF/Writer.cpp
1332

My understanding is that we'll be sorting the table after relocation.

The .ARM.exidx table doesn't contain addresses. It comes in one of two forms:

PREL31 offset to functionPREL31 offset to table (bit 31 = 1)
PREL31 offset to functionInline table entry (bit 31 = 0)

Where PREL31 is a signed offset ignoring bit 31.

Post-relocation there can be duplicate PREL31 offsets so we can't sort on this alone, as far as I can tell the sorting comparison function won't know enough to be able to calculate a relative order of the PREL31 offsets. Reordering will also break all the offsets so they'll need to be recalculated.

This isn't insolvable. One possible solution could be to generate a parallel table with the final addresses, sort that and then recalculate the table contents.