[llvm-dev] [lld] MIPS ELF -> ELF2 porting
Simon Atanasyan via llvm-dev
llvm-dev at lists.llvm.org
Sat Oct 31 05:20:02 PDT 2015
On Sat, Oct 31, 2015 at 12:03 PM, Igor Kudrin <ikudrin.dev at gmail.com> wrote:
> I'd like to study it and MIPS target looks promising for my goal.
> I'd be happy to hear any comments for my patches and any advice
> what to do next.
Good point. As to me I would start from static linking a trivial Hello
World application. To do that we need to fix at least the following
1. Handle R_MIPS_HI16 / R_MIPS_LO16 relocations
The non-trivial thing here is that these relocations should be handled
together. In short you need to keep and do not apply all R_MIPS_HI16
relocations until you get R_MIPS_LO16 relocation with the same target.
Then you calculate "combined" addend as (AHI << 16) + (short)ALO,
where AHI is R_MIPS_HI16 addend and ALO is R_MIPS_LO16 addend, and use
this "combined" addend to apply relocations.
2. Handle R_MIPS_GOT16 relocation for local symbols
In that case R_MIPS_GOT16 immediately followed with R_MIPS_LO16
relocation. You need to calculate "combined" addend too. Then you use
this addend to calculate a relocation result. The low 16-bits is
written to the R_MIPS_LO16 relocation destination. The high 16-bits
needs to be stored in the GOT. The corresponding GOT offset is written
to the R_MIPS_GOT16 relocation destination. At the first step we can
skip GOT size optimization and create new GOT entry for each new
symbol targeted by the relocation. But obviously there will be many
duplicated GOT entries because all symbols from a 64kb range has the
same high 16-bits. As the second step we need to escape the
duplication entries as much as possible.
Right now I cannot allocate a time for active work on ELF -> ELF2
porting. But going to do that later. Feel free to ask any questions,
More information about the llvm-dev