Page MenuHomePhabricator

[LLD][ELF] Introduce Thunk reuse compatibility
ClosedPublic

Authored by peter.smith on Jun 8 2017, 7:10 AM.

Details

Summary

On ARM the interworking thunks are only produced for branch instructions that can't be changed into a blx instruction so only Thumb callers would call Thumb thunks and only ARM callers would call ARM thunks. With range extension thunks branch and link instructions may need a Thunk. These instructions can be rewritten as a blx and can use either ARM or Thumb thunks.

We introduce a compatibleWith() function so that a caller can check if an existing Thunk is compatible before reusing it. With the currently supported interworking thunks all the thunks are reusable by construction so there will be no impact on the tests.

Diff Detail

Repository
rL LLVM

Event Timeline

peter.smith created this revision.Jun 8 2017, 7:10 AM

Is there any more I can do to explain this patch?

In the current Thunk implementation we only permit 1 Thunk per Target symbol and by construction all callers to that symbol are compatible with the Thunk. Once we have range extension thunks this will no longer be the case. For example we might have ARM and Thumb branches (can't use blx) to a target symbol S, these callers cannot share the same Thunk.

This patch by construction will return true for all the currently supported thunks.

@ruiu , can you please look at this?

At least one person has asked me when range thunks for ARM will be ready. I'd like to post the full feature for review and maintain it so that if anyone wants to play about with it they can.
This is patch 1 of 11 of range thunks.

I've posted the full range thunks implementation in a single patch for them in https://reviews.llvm.org/D34634 . This can be used for context on how I'm intending the final code to look.

Is there anything I can do to help get the Range Thunks patches looked at? To avoid pinging 11 separate patches I've listed all the reviews here and what the intention behind them is. I'm happy to restructure these in a different way if that would help?

There are 11 patches to get to a full implementation.
These two don't need to touch anything outside of the Thunk implementation, they don't add any functionality, but do prepare some of the groundwork.
D34035 [LLD][ELF] Introduce Thunk reuse compatibility
D34037 [LLD][ELF] Allow multiple thunks to be added for a symbol.

These two are the only significant changes outside of the Thunk implementation, for range thunks what I need to do is to be able to calculate addresses in order to check ranges. This is just one approach to get to that point, I'm happy to go for a different approach or help in any refactoring.
D34344 [LLD][ELF] Extract allocateHeaders() from assignAddresses()
D34345 [LLD][ELF] Reset any accumulated state before calculating addresses
D34688 [LLD][ELF] Add call to assignAddresses() before createThunks() [NFC]

These patches apart from one small change to Writer.cpp to enable multiple passes in D34692 are all within the Thunk implementation. The design for range thunks is to use the address information to pre-create one or more ThunkSections per InputSectionDescription that we can use place Thunks in range of their callers. D34691 is enough for simple cases, D34692 deals with corner cases that can occur if you are unlucky.
D34689 [LLD][ELF] Pre-create ThunkSections at Target specific intervals
D34690 [LLD][ELF] Introduce target specific inBranchRange() function
D34691 [LLD][ELF] Introduce range extension thunks for ARM
D34692 [LLD][ELF] Add support for multiple passes to createThunks()

I've separated out the test cases as they are by far the largest amount of changes. The majority need all the changes in D34692 to run successfully. I could extract some of these tests for 34691
D31665 [LLD][ELF] Add test cases for range extension thunks (no linkerscripts)
D31666 [LLD][ELF] Add test cases for range extension thunks using linker scripts

This revision was automatically updated to reflect the committed changes.