[PATCH] D29129: [LLD][ELF] Use Thunks for Synthetic Sections

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 25 08:21:56 PST 2017


peter.smith created this revision.
Herald added a subscriber: aemerson.

Thunks are now implemented by redirecting a relocation to the symbol S, to a symbol TS defined in a Thunk. The Thunk will transfer control to S. This has the following implications:

- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections

This implementation is almost a direct conversion of the existing Thunks with the following exceptions:

- Mips LA25 Thunks are placed before the InputSection that defines the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the first caller to the Thunk.

Range extension Thunks are not supported yet so it is optimistically assumed that all Thunks can be reused.

Design decisions:
I've used the synthetic section as a container for multiple thunks. This minimises the number of insertions into the InputSections, makes it easier to insert multiple Mips LA25 thunks before the target InputSection, and will make it easier to support range-extension thunks as Gold and ld.bfd implement them (thunk pools placed at regular intervals). Alternatives would be a single Thunk per SyntheticSection or derive each Thunk from SyntheticSection.

I've put the Mips LA25 Thunks ahead of the Target Input Section as Simon has mentioned that this will enable an optimization to allow control to drop through into the next section without a jump instruction. I have not implemented that optimization.

As the Thunks define symbols they need to be ahead of the code that adds symbols into the symbol table so I've moved the createThunks call to before the code to finalize the SymTab.

There isn't a standard naming convention for Thunks, every ARM linker does it differently, I've somewhat arbitrarily chosen names that are close to the Thunk class names, but do not have a strong opinion what we should use. I find it helpful to have the symbol for the Thunk displayed in disassembly.

I expect that supporting range extension thunks will need quite a bit of change to the code in createThunks(). The current implementation is only good enough to handle Mips LA25 Thunks that need precise insertion, and ARM Thunks that can go at the end of the OutputSection.


https://reviews.llvm.org/D29129

Files:
  ELF/InputFiles.cpp
  ELF/InputSection.cpp
  ELF/InputSection.h
  ELF/LTO.cpp
  ELF/LTO.h
  ELF/Relocations.cpp
  ELF/Relocations.h
  ELF/SymbolTable.cpp
  ELF/Symbols.cpp
  ELF/Symbols.h
  ELF/SyntheticSections.cpp
  ELF/SyntheticSections.h
  ELF/Target.cpp
  ELF/Target.h
  ELF/Thunks.cpp
  ELF/Thunks.h
  ELF/Writer.cpp
  test/ELF/arm-thumb-interwork-shared.s
  test/ELF/arm-thumb-interwork-thunk.s
  test/ELF/mips-npic-call-pic.s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D29129.85754.patch
Type: text/x-patch
Size: 72704 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170125/f311717c/attachment.bin>


More information about the llvm-commits mailing list