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

[Rui Ueyama via llvm-dev]

On Sun, Nov 22, 2015 at 10:18 PM, Simon Atanasyan <simon at atanasyan.com>
wrote:

> On Mon, Nov 23, 2015 at 6:39 AM, Rui Ueyama <ruiu at google.com> wrote:
> > 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?
>
> HI16 and LO16 applied to the different place in the code. Take a look
> at the typical example below. So you have to apply the relocations
> separately but calculate them together.
>
> 00000000 <main>:
>    0:   3c1c0000        lui     gp,0x0
>                         0: R_MIPS_HI16  _gp_disp
>    4:   279c0000        addiu   gp,gp,0
>                         4: R_MIPS_LO16  _gp_disp
>
> HI16 / LO16 relocations use a combined addend AHL. The R_MIPS_LO16
> uses low 16 bits of the (S + AHL) expression so HI16 addend does not
> affect its result. But LO16 addend might affect the result of the HI16
> relocation.
>

One way to handle that would be to use a stack to save previous locations
of HI16 relocations. When you see a LO16 relocation, pop an address from
the stack, and fix the address at that location.

That should work, but I can see a problem: that makes Target stateful.
That's probably we should avoid since we want to apply relocations in
parallel in future.

So maybe you want to search for a corresponding LO16 relocation when you
see a HI16 relocation at least for now? I have no good idea about how to
handle them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151123/a44d8de5/attachment.html>