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

Rafael EspĂ­ndola via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 6 13:34:04 PDT 2017

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


> 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.


More information about the llvm-dev mailing list