[llvm-dev] [lld] R_MIPS_HI16 / R_MIPS_LO16 calculation

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 22 19:39:30 PST 2015


On Sun, Nov 22, 2015 at 3:05 AM, Simon Atanasyan <simon at atanasyan.com>
wrote:

> On Sun, Nov 22, 2015 at 1:28 AM, Rui Ueyama <ruiu at google.com> wrote:
> > I'm not sure if I understand the semantics of HI16 and LO16 relocations.
> If
> > my understanding is correct, a pair of HI16 and LO16 represents an addend
> > AHL. AHL is computed by (AHI<<16) | (ALO&0xFFFF). Can't we apply HI16 and
> > LO16 relocations separately and produce the same relocation result? Do we
> > have to pair them up before applying relocations?
>
> The correct formula for the combined addend is (AHI << 16) +
> (short)ALO. So the combined addend depends on both AHI and ALO
> addends, therefore ALO affects result of R_MIPS_HI16 relocation.


Does that mean it is impossible to process HI16 and LO16 separately?

If you apply only HI16 relocation, the relocation target will have a value
AHI<<16. Next time when you apply LO16 relocation to the same address,
you'll be able to see the previous result of HI16 relocation. So you don't
have to combine them before applying relocations, no?


>
> Current version of bfd GNU linker looks up R_MIPS_LO16 relocation each
> time it needs to calculate R_MIPS_HI16 relocation. It uses
> `mips_elf_add_lo16_rel_addend` function for that
> (https://goo.gl/P7nb76).
>
> --
> Simon Atanasyan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151122/9a112b2c/attachment.html>


More information about the llvm-dev mailing list