<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 21, 2015 at 7:34 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"><div class="HOEnZb"><div class="h5">On Sat, Nov 21, 2015 at 10:08 AM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Fri, Nov 20, 2015 at 11:02 PM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>
> wrote:<br>
>><br>
>> On Sat, Nov 21, 2015 at 9:28 AM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>> > On Fri, Nov 20, 2015 at 10:13 PM, Simon Atanasyan <<a href="mailto:simon@atanasyan.com">simon@atanasyan.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16<br>
>> >> relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses<br>
>> >> combined addend (AHI << 16) + (short)ALO where AHI is original<br>
>> >> R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16<br>
>> >> relocation [1]. There are two methods to do matching and R_MIPS_HI16<br>
>> >> calculation.<br>
>> >><br>
>> >> Method A:<br>
>> >> 1. Postpone R_MIPS_HI16 relocation calculation and record its<br>
>> >> arguments.<br>
>> >> 2. When R_MIPS_LO16 is found, iterate over recorded R_MIPS_HI16<br>
>> >> relocations, calculate combined addend and apply relocations.<br>
>> >> 3. At the end check orphaned (without R_MIPS_LO16 pair) R_MIPS_HI16<br>
>> >> relocations, show warnings and apply them with zero addend.<br>
>> >><br>
>> >> Method B:<br>
>> >> 1. Each time we have found R_MIPS_HI16 relocation, iterate remaining<br>
>> >> relocations list to find matching R_MIPS_LO16.<br>
>> >> 2. Calculate combined adddend and apply relocation or show warning if<br>
>> >> the R_MIPS_LO16 is not found.<br>
>> >><br>
>> >> Method A requires some sort of container to keep postponed HI16<br>
>> >> relocations. If we add the container to the `MipsTargetInfo` class we<br>
>> >> will be able to hide all this unusual scheme inside MIPS specific code<br>
>> >> and will not need to perform LO16 lookups. But the `MipsTargetInfo`<br>
>> >> becomes stateful.<br>
>> >><br>
>> >> Method B keeps the `MipsTargetInfo` stateless but requires forward<br>
>> >> LO16 lookup for each HI16 relocation and requires to provide an<br>
>> >> interface for such lookup to the `MipsTargetInfo`.<br>
>> >><br>
>> >> Sure we can implement each of these methods somewhere in the<br>
>> >> `InputSectionBase` class under `if (MIPS)` statements.<br>
>> >><br>
>> >> Any opinions about the best method / approach?<br>
>> ><br>
>> ><br>
>> > If I understand that spec correctly, an R_MIPS_HI16 should immediately<br>
>> > be<br>
>> > followed by an R_MIPS_LO16. Can't you use that property? It doesn't seem<br>
>> > to<br>
>> > me that you really have to search and pair up HI16 and LO16 relocations.<br>
>><br>
>> It is a question what the ABI authors did mean by the "R_MIPS_HI16<br>
>> must have an associated R_MIPS_LO16 entry immediately following it"<br>
>> phrase. In fact you can get from a compiler this code:<br>
>><br>
>> lui $t0,%hi(sym1+4) # R_MIPS_HI16<br>
>> lui $t0,%hi(sym1+8) # R_MIPS_HI16<br>
>> lui $t0,%hi(sym1+12) # R_MIPS_HI16<br>
>> addi $t0,$t0,%lo(sym1+16) # R_MIPS_LO16<br>
><br>
><br>
> The first two relocations don't conform to the standard because there are no<br>
> corresponding LO16 relocations, no?<br>
><br>
>> and even such code:<br>
>><br>
>> lui $t0,%hi(sym1) # R_MIPS_HI16 on sym1<br>
>> lui $t0,%hi(sym2) # R_MIPS_HI16 on sym2<br>
>> addi $t0,$t0,%lo(sym1) # R_MIPS_LO16 on sym1<br>
>> addi $t0,$t0,%lo(sym2) # R_MIPS_LO16 on sym2<br>
><br>
><br>
> Hmm, isn't this a violation of the ABI? My interpretation of "[e]ach<br>
> relocation type of R_MIPS_HI16 must have an associated R_MIPS_LO16 entry<br>
> immediately following it in the list of relocations" is not ambiguous to<br>
> allow them. Is there any chance to fix the compiler? (I guess there isn't,<br>
> though.)<br>
<br>
</div></div>Strictly speaking yes, it is a violation. But it is not a bug of the<br>
single compiler. You can find such code everywhere from various<br>
versions of libc compiled by different versions of gcc and to the code<br>
produced by Clang.<br>
<br>
Moreover, I scan through the libc code and found some places where<br>
R_MIPS_HI16 / R_MIPS_LO16 pairs are interleaved with other types of<br>
relocations.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Simon Atanasyan<br>
</font></span></blockquote></div><br></div>