This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by peter.smith on Mar 6 2017, 3:56 AM.



For the Mips LA25 Thunks we want the Thunks to precede the target section. The existing code merges these thunks into OutputSections::Sections. This is not sufficient when linker scripts are used as the order of sections and the addresses assigned to them are determined by the InputSectionDescription in the LinkerScript, and thunks are generated after the InputSectionDescription contents have been generated.

This change merges the LA25 Thunks into the InputSectionDescription as well as the OutputSections so that the ordering of the Thunks is maintained. To do this we need to ask the script to calculate the offsets of the OutputSection as all the offsets for script controlled OutputSections are 0 at thunk creation time. We need to ask the script to calculate the offsets as there may be multiple InputSectionDescriptions with location expressions in between them.

The state is cleared at the start of the Linker Script address assignment as we will be running this function twice when Thunks are created.

I've gone for an implementation that merges the result of the createThunks() function into the InputSectionDescription. An alternative is to rewrite createThunks to work on ranges of InputSectionData and have createThunks ask the script for the InputSectionDescription ranges. I'm open to suggestions on how best to work out how scripts and thunks interact as range extension thunks will need to deal with location expressions.

I've based this on top of D30637.

Diff Detail

Event Timeline

peter.smith created this revision.Mar 6 2017, 3:56 AM
rafael added inline comments.Apr 3 2017, 1:29 PM

This is similar to what will have to be done for range thunks, no?


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.

peter.smith abandoned this revision.Apr 4 2017, 3:54 AM

Abandoning this revision in favour of D31656, which is more general and can handle range extension thunks.