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

["Maciej W. Rozycki" <macro at codesourcery dot com>]

Richard,

> 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...

> 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?

  Maciej