<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Nov 22, 2015 at 3:05 AM, 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 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. If<br>
> my understanding is correct, a pair of HI16 and LO16 represents an addend<br>
> AHL. AHL is computed by (AHI<<16) | (ALO&0xFFFF). Can't we apply HI16 and<br>
> LO16 relocations separately and produce the same relocation result? Do we<br>
> have to pair them up before applying relocations?<br>
<br>
</span>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.</blockquote><div><br></div><div>Does that mean it is impossible to process HI16 and LO16 separately?</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Current version of bfd GNU linker looks up R_MIPS_LO16 relocation each<br>
time it needs to calculate R_MIPS_HI16 relocation. It uses<br>
`mips_elf_add_lo16_rel_addend` function for that<br>
(<a href="https://goo.gl/P7nb76" rel="noreferrer" target="_blank">https://goo.gl/P7nb76</a>).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Simon Atanasyan<br>
</font></span></blockquote></div><br></div></div>