[llvm-dev] [lld] MIPS ELF -> ELF2 porting
Igor Kudrin via llvm-dev
llvm-dev at lists.llvm.org
Sat Oct 31 06:19:09 PDT 2015
Thank you very much for the suggestions; I'll start investigations on
31 окт. 2015 г. 18:20 пользователь "Simon Atanasyan" <simon at atanasyan.com>
> On Sat, Oct 31, 2015 at 12:03 PM, Igor Kudrin <ikudrin.dev at gmail.com>
> > 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,
> hints etc.
> Simon Atanasyan
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev