[PATCH] D30641: [LLD][ELF] Fix ordering of Mips LA25 Thunks when Linker Script used

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 4 02:14:03 PDT 2017


Yes this is similar to what will be needed with range thunks. I've
come up with a slightly different way of doing this that works for
range thunks and Mips LA25 Thunks, I'll withdraw this revision as I'll
be posting that later today.

I agree that the different representations between script and
non-script are not ideal. I'll put some thoughts into the new review.





On 3 April 2017 at 21:29, Rafael Ávila de Espíndola via Phabricator
<reviews at reviews.llvm.org> wrote:
> rafael added inline comments.
>
>
> ================
> Comment at: ELF/LinkerScript.cpp:555
> +// this permits addressAssignment to be run again.
> +template <class ELFT> void LinkerScript<ELFT>::resetAddressState() {
> +  LMAOffset = 0;
> ----------------
> This is similar to what will have to be done for range thunks, no?
>
>
> ================
> Comment at: ELF/LinkerScript.cpp:691
> +// assigns the Thunk the correct address.
> +template <class ELFT>
> +void LinkerScript<ELFT>::addInlineThunks(
> ----------------
> This points out an annoyance with having the different representations of how we handle linker scripts and non linker script cases.
>
> When we need to add a thunk, we have to figure out where it goes in both cases. For the non linker script case, it is just a list of input sections. For the linker script case it is the a list of commands. This will be particularly annoying for the range extension thunks.
>
> I wonder if this can be simplified. The only thing that comes to mind is to have the non script case create a pseudo linker script when none is given. It would include only output section commands. If we can make creating and executing that script really fast, it should be possible to figure out where to insert thunks only once.
>
> For this it would be critical that the commands are pre resolved, we should not be looking at section names if we don't have too.
>
>
>
> https://reviews.llvm.org/D30641
>
>
>


More information about the llvm-commits mailing list