Simon Atanasyan via llvm-dev
2015-Oct-31 12:20 UTC
[llvm-dev] [lld] MIPS ELF -> ELF2 porting
Hello, 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 issues: 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. Regards, Simon Atanasyan
Hello Simon, Thank you very much for the suggestions; I'll start investigations on Monday. Regards, Igor 31 окт. 2015 г. 18:20 пользователь "Simon Atanasyan" <simon at atanasyan.com> написал:> Hello, > > 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 > issues: > > 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. > > Regards, > Simon Atanasyan >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151031/33fb542b/attachment.html>