[PATCH] D17934: [ELF] Implement infrastructure for thunk code creation

[Simon Atanasyan via llvm-commits]

atanasyan added a comment.

In http://reviews.llvm.org/D17934#374020, @ruiu wrote:

> This looks still a bit too intrusive. The code to handles thunks appears too many places.
>
> Maybe we should handle thunks as a separate output section? Then we don't need to add addThunk to the regular output section class and we don't have to update the code to calculate section size and offsets.


I see some problems here:

- We can get a really long out-of-range jumps. I remember that my initial solution had the same problem but it was my mistake.
- The output section should have a name. Putting all thunks into the separate output section is in fact ABI extension because we have to choose dedicated unique name for such section. Moreover if somebody have a linker script to put output sections in exact places (common case for embedded software developers), it will be surprise that he or she have to handle one more unusual output section.
- There is optimization used by bfd and gold linkers - if input section contains the only function and we need to create a thunk for it, we can place the thunk in the beginning of the section and use just two assembly instructions to save the function address into the $25 registers and do not use additional jump instructions at all. My patch does not implement this optimization yet but moving all thunks into the separate output section make such optimization impossible at all.

I think the less intrusive solution is to concentrate the thunk handling in the InputSection class. We can add a vector of SymbolBody pointers right to this class. In that case only InputSection and TargetInfo descendant will know about synthetic code.

BTW MIPS is not the only target uses thunks. AFAIK ARM has concept of veneer.


Repository:
  rL LLVM

http://reviews.llvm.org/D17934