llvm dev - Apr 2017 - [LLD] RFC Range Thunks Implementation review for ARM and Mips

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

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

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