<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 22, 2015 at 10:18 PM, Simon Atanasyan <span dir="ltr"><<a href="mailto:simon@atanasyan.com" target="_blank">simon@atanasyan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 23, 2015 at 6:39 AM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Sun, Nov 22, 2015 at 3:05 AM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>
> wrote:<br>
>><br>
>> On Sun, Nov 22, 2015 at 1:28 AM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>> > I'm not sure if I understand the semantics of HI16 and LO16 relocations.<br>
>> > If<br>
>> > my understanding is correct, a pair of HI16 and LO16 represents an<br>
>> > addend<br>
>> > AHL. AHL is computed by (AHI<<16) | (ALO&0xFFFF). Can't we apply HI16<br>
>> > and<br>
>> > LO16 relocations separately and produce the same relocation result? Do<br>
>> > we<br>
>> > have to pair them up before applying relocations?<br>
>><br>
>> The correct formula for the combined addend is (AHI << 16) +<br>
>> (short)ALO. So the combined addend depends on both AHI and ALO<br>
>> addends, therefore ALO affects result of R_MIPS_HI16 relocation.<br>
><br>
><br>
> Does that mean it is impossible to process HI16 and LO16 separately?<br>
><br>
> If you apply only HI16 relocation, the relocation target will have a value<br>
> AHI<<16. Next time when you apply LO16 relocation to the same address,<br>
> you'll be able to see the previous result of HI16 relocation. So you don't<br>
> have to combine them before applying relocations, no?<br>
<br>
</span>HI16 and LO16 applied to the different place in the code. Take a look<br>
at the typical example below. So you have to apply the relocations<br>
separately but calculate them together.<br>
<br>
00000000 <main>:<br>
0: 3c1c0000 lui gp,0x0<br>
0: R_MIPS_HI16 _gp_disp<br>
4: 279c0000 addiu gp,gp,0<br>
4: R_MIPS_LO16 _gp_disp<br>
<br>
HI16 / LO16 relocations use a combined addend AHL. The R_MIPS_LO16<br>
uses low 16 bits of the (S + AHL) expression so HI16 addend does not<br>
affect its result. But LO16 addend might affect the result of the HI16<br>
relocation.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>