[PATCH] D32233: [LLD][ELF] User linkerscript InputSectionDescription for .ARM.exidx dependency order

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

I can think of some options, although each has their own trade-off. Apologies for the length of the answer.

To restate what I think the requirements are:

1. All of the .ARM.exidx* sections need to be placed contiguously in one "table".
2. The order of the .ARM.exidx* sections needs to match the order of the code sections that the .ARM.exidx sections have a link order dependency to.

For non-linker script links, or linker script links where .ARM.exidx sections are all orphans we use the naming rules to ensure that there is a single .ARM.exidx OutputSection containing all the .ARM.exidx* InputSections, that takes care of requirement 1.
For linker script links where .ARM.exidx sections are not orphans we are somewhat reliant on the user to get the pattern right to satisfy 1.) The best pattern is .ARM.exidx : { *(.ARM.exidx*) }, but .ARM.exidx : { *(.ARM.exidx) } without the trailing * will work as the .ARM.exidx.foo sections will be orphans.

At the moment if all .ARM.exidx sections are orphans or there is no linker script we can sort the OutputSections::Sections directly to satisfy 2.)
If any of the .ARM.exidx sections are covered by a linker script, our current Output::Sections sort will be ignored by the Script->assignAddresses() and we are likely to not satisfy 2.)

With this in mind, I think the options are:
1.) Do not include .ARM.exidx sections in any InputSectionDescription::Section, they will always be added as orphans, this will either mean some special case code in LinkerScripts to not add the sections, or some code to go in and remove them from the InputSectionDescriptions prior to final address assignment. This would allow the existing direct sorting approach to work as the script's handling of orphans would just work.
2.) Do what I originally proposed for RangeThunks and synchronize/rewrite the output of sorting OutputSection::Sections with the InputSectionDescriptions. I think that this is just a different way of implementing option 1.) but putting the special case code after, rather than before.
3.) The option above, which is to work entirely in InputSectionDescription::Section. This doesn't require quite so much special case code in LinkerScripts for .ARM.exidx, but it does mean that the sorting code has to cope with linker scripts that have multiple InputSectionDescriptions due to orphans or just users writing something like .ARM.exidx : { *(.ARM.exidx) *(.ARM.exidx.foo*) }.

I think that option 1 could end up being simpler overall. I'm going to be at a conference for the rest of the week, but if I can't get something finished today I'll do so early next week.


https://reviews.llvm.org/D32233