Add Thunk support framework for ARM and Mips
Generalise the Mips LA25 Thunk code and implement ARM and Thumb interworking Thunks.
- Introduce a new module Thunks.cpp to store the mapping between SymbolBody and Thunk
- SymbolBody now has no Thunk specific fields
- A Target can more easily have more than one type of Thunk
- Support PC-relative calls to Thunks
- Support Thunks to PLT entries
- Existing Mips LA25 Thunk code integrated with no change in behaviour
- Support for ARMv7A interworking Thunks
- Added pc-relative versions of MOVT/MOVW relocations needed by ARM Thunks
- Tests for new functionality added.
Limitations:
- Only one Thunk per SymbolBody, this is sufficient for all currently implemented Thunks.
- ARM thunks assume presence of V6T2 MOVT and MOVW instructions.
Notes for reviewers:
- It is just about possible to implement ARM/Thumb interworking Thunks in the same framework as the Mips LA25 Thunks. However this does mean adding new fields in RegularSymbol and SharedSymbol to record information about the InputSection that the Thunk will be written to. Given that the majority of Symbols even in ARM will have no Thunks I thought it better to move the Thunk information away from SymbolBody.
- The code in Thunk.cpp could be moved into Target.cpp although if the ThunkInfo class were merged into TargetInfo it would mean templating TargetInfo with ELFT. I also thought that the Thunk code was less interesting to Targets other than ARM or Mips.
- In this patch I've chosen to keep the Mips Thunk code in Target undisturbed rather than moving it into Thunks.cpp. This is partly due to the MipsTargetInfo<ELFT>::writeThunk member function calling local static functions in Target.cpp. It also means less rework if Thunks.cpp isn't the right design.
- Most of the other changes are moving existing code around to deal with the Thunks module.
- I think that the implementation can be extended to cope with range-extension Thunks. In summary a SymbolBody will map to multiple Thunks, a caller will select the most appropriate Thunk out of the possible candidates.
Parameters need to be in camel case as a rule, so thunk is not okay. In this context, I'd just name this T.