Handle ARM exception table.
Details
Diff Detail
Event Timeline
ELF/Writer.cpp | ||
---|---|---|
1332 | Is it possible to have duplicate / alias symbols here? If so, should this be a stable_sort? |
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:
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. |
Is it possible to have duplicate / alias symbols here? If so, should this be a stable_sort?