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

[Peter Smith via llvm-dev]

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