[llvm-dev] [LLVM-DEV][LLD] RFC Range Thunks Implementation review for ARM and Mips

[Peter Smith via llvm-dev]

I've made a bit more progress with converting createThunks() to use
InputSectionDescriptions. I've created https://reviews.llvm.org/D32030
just to hold a first draft of the diff to show where it is going (not
a review request). The experience so far is:
- The .ARM.exidx SHF_LINK_ORDER section sorting can be broken by the
LinkerScript sorting in the same way as Thunks can be. In essence we
sort the OutputSections::Sections, which can be broken by
Script->assignAddresses() if any part of the .ARM.exidx is covered by
the linker script.
- It isn't sufficient to just fabricate InputSectionDescriptions when
there is no SECTIONS command, we must fabricate
InputSectionDescriptions to cover the orphan sections as well.
- There is a lot of scope to find a better interface to getting the
InputSectionDescriptions
- There will need to be some optimization as there is quite a lot of
looking up by name.

Peter

On 10 April 2017 at 16:20, Peter Smith <peter.smith at linaro.org> wrote:
> I've made an attempt at unifying the address assignment as suggested
> at https://reviews.llvm.org/D31888
>
> This creates equivalent linker script commands for the OutputSections.
> There was one test ELF/tls-offset.s that I had to update as the way
> that Writer::assignAddresses() calculates the address of a following
> non .tbss section is different to the linker script, in particular the
> linker script won't allow setDot() to give a lower address I've
> updated the test to match the equivalent linker script.
>
> The review only changes the existing call to assignAddresses() which
> happens after createThunks(). Next experiment is to call
> assignAddresses() before createThunks() and rewrite createThunks() to
> use InputSectionDescriptions.
>
> Peter
>
> On 7 April 2017 at 11:10, Peter Smith <peter.smith at linaro.org> wrote:
>> Thanks for the comments. I'm happy to start with no linker script
>> support, it would be sufficient to get clang built which enables an
>> ARM clang, lld, test-suite build bot.
>>
>> Peter
>>
>> On 6 April 2017 at 21:34, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>> On 6 April 2017 at 07:01, Peter Smith <peter.smith at linaro.org> wrote:
>>>> My understanding is that this would be (initially) limited to
>>>> fabricating enough linker script commands such that we could replace:
>>>> fixSectionAlignments()
>>>> assignAddresses()
>>>> Script->processNonSectionCommands()
>>>>
>>>> With something like:
>>>> Script->assignAddresses() // Could be done multiple times
>>>> Script->processNonSectionCommands() // This should only be done once
>>>
>>> Correct.
>>>
>>>> In theory all the other __start and __end symbols could still be kept
>>>> separate if the linker script commands were created late, and in a
>>>> compatible way. I also don't think that this means removing
>>>> OutputSections::Sections just yet either?
>>>
>>> Probably not, but it might got away in the future.
>>>
>>>> I don't think that we are proposing to follow the ld.bfd model of
>>>> driving the default case via a built in linker script yet? I think
>>>> that this would be considerably more work than just this limited
>>>> change.
>>>
>>> I really *don't* want to see lld do that. Using a real linker script
>>> is a bad idea is it forces the link to be section name based. There is
>>> no way to combine sections based on their flags for example.
>>>
>>> We would still have exactly the same logic as to how sections are
>>> combined. We would then just create the same structure that the linker
>>> script address assignment logic uses.
>>>
>>> Before any of this, we have to move all name based logic out of assignAddresses.
>>>
>>>> I think the best way forward is to try and prototype something to see
>>>> if it splashes out any special cases. I can give this a go to see what
>>>> happens.
>>>
>>> Cool. I am going on vacation tomorrow night, but I will try to at
>>> least move some of the string lookups before assign address.
>>>
>>>> In the meantime I would be grateful if there is any opportunity to
>>>> move forward some of the range thunks changes in parallel, even if
>>>> they do not initially work with some linker scripts.
>>>
>>> Could we maybe start with *no* linker script support? If the idea of
>>> unifying the representation works out we will get that for free.
>>>
>>> Cheers,
>>> Rafael