Re: RFC: Possible tweak to MIPS16/microMIPS PLT choice

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>> While writing some tests for the MIPS16 and microMIPS PLT stuff
>> to address http://article.gmane.org/gmane.comp.gnu.binutils/61257
>
>  I still owe you a new version of the test suite part proposed there, I 
> remember -- I just couldn't allocate any time to do that, sigh...

NP -- I have a harnaess I'm happy with, I just need to fill in the details :-)

>> there was one corner case where the handling seemed a bit counter-
>> intuitive.  If a function is referenced by both HI/LO relocations
>> and a JAL relocation, the ISA encoding of the JAL decides the encoding
>> of the PLT, as intended.  But if a function is referenced by both HI/LO
>> relocations and a GOT CALL relocation (but not by JAL relocations),
>> the ISA encoding of the GOT CALL reference doesn't influence the encoding
>> of the PLT.  This means that:
>> 
>> 1. microMIPS CALL reloc + HI/LO ref -> microMIPS PLT
>> 2. MIPS16 CALL reloc    + HI/LO ref -> MIPS PLT
>> 3. MIPS CALL reloc      + HI/LO ref in non-microMIPS object -> MIPS PLT
>> 4. MIPS CALL reloc      + HI/LO ref in microMIPS object     -> microMIPS PLT
>> 
>> (1) and (3) are obviously right, but (2) and (4) were less obvious.
>> With a patch like the attached, we'd use the GOT CALL relocs as a
>> fall-back when choosing the encoding.  No change log, since it's an RFC.
>> 
>> I don't really have a strong opinion either way.  It's just that these
>> things are harder to change once they're enshrined in tests, so I'd like
>> to be sure of the behaviour.
>
>  Hmm, I'm not sure if I follow you.  The choice looks obvious to me: we 
> want to use microMIPS PLT entries whenever possible because they are 
> smaller (the whole purpose of the creation of the microMIPS ISA).  In your 
> scenario:
>
> 1. We obviously can use a microMIPS PLT entry because we have microMIPS 
>    code in the object being linked.
>
> 2. We obviously can't use a microMIPS PLT entry because the presence of 
>    MIPS16 code precludes the use of microMIPS code.
>
> 3. We obviously can't use a microMIPS PLT entry because we only saw 
>    standard MIPS code and therefore we want to run it on a standard MIPS 
>    processor.
>
> 4. We obviously can use a microMIPS PLT entry because we have microMIPS
>    code in the object being linked.
>
> -- so what's unclear about it?
>
>  In the absence of JAL relocations it's the output microMIPS ELF file 
> header flag that makes BFD decide whether to use microMIPS or standard PLT 
> entries and it seems obvious and straightforward to me.  Why do you think 
> CALL relocations should be treated specially in any way?  Am I missing 
> anything?

Yeah, I should have been more explicit, sorry.  I thought the justification
for using MIPS PLTs in microMIPS objects, rather than converting MIPS
JALs to JALXs, was that we wanted to use the caller's encoding to avoid
the hit of a mode change.  Wouldn't the hit be just the same if the call
is coming indirectly through a JALR rather than directly through a JALX?

That is, I wasn't sure why we were treating:

        jal     foo

and the equivalent of:

        lw      $25, %call16(foo)($25)
        jalr    $25

differently when deciding the encoding of foo.  With JAL->JALX conversion,
both forms can call either "standard" or "compressed" code, but as things
stand, they don't influence the choice in the same way.

So going back to the list above, the equivalent for JAL relocations is:

1. microMIPS JAL + HI/LO ref -> microMIPS PLT
2. MIPS16 JAL    + HI/LO ref -> MIPS16 PLT
3. MIPS JAL      + HI/LO ref in non-microMIPS object -> MIPS PLT
4. MIPS JAL      + HI/LO ref in microMIPS object     -> MIPS PLT

where (2) and (4) give different results from the GOT CALL case.
I was thinking the GOT CALL and JAL cases could be handled in the same way.

Thanks,
Richard