Re: [PATCH] libgcc/MIPS: Fill in delay slots of (some) MIPS16 call stubs

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

On Mon, 29 Jul 2013, Richard Sandiford wrote:

> >  I believe the only legacy MIPS processors that implemented the MIPS16 ASE 
> > in its original variation (i.e. with no compact jumps, no SAVE/RESTORE, 
> > and no extend instructions) were the LSI's TinyRISC cores.
> 
> Ah, hadn't realised that the original version had no EXTEND instruction.
> Which TinyRISC iteration was that?  The LR4102 had it AFAIK.
> 
> FWIW GCC and binutils always assume that EXTEND is available and just
> make a distinction between "original MIPS16" (which sounds like it might
> not be as original as I'd thought) and "MIPS16e".  The VR4121 and VR4131
> were also in the "original MIPS16" category (no compact jumps, SAVE/RESTORE,
> etc.).  But they also had no FPU.

 I meant the sign- and zero-extend instructions indeed, not the EXTEND 
opcode (not really a distinct instruction, more like a prefix), sorry for 
not being clear enough.  Thanks for the reminder of the NEC silicon.

> >  These stubs are I believe not really covered in our testing, because they 
> > require a mixed standard-MIPS/MIPS16 environment.
> 
> What's the barrier to testing a mixed environment?  The normal *-linux-gnu
> configurations have no MIPS16 multilibs, so you should be able to test it
> on a plain mips-linux-gnu configuration using --target_flags unix/-mips16.
> FWIW I've been using the mips64-linux-gnu equivalent
> (--target_flags unix/-mabi=32/-mips16) without problems.  
> 
> Or if you don't want to test on GNU/Linux, you should be able to use something
> like mips64-elf configured with whichever --with-arch= you like (and an
> appropriate simulator).  Long time since I tried that though.  I prefer
> testing on GNU/Linux because it also covers libgcc.so symbol visibility
> and has better libgfortran support.

 We don't have specific coverage, but something in the testsuite might 
happen to pull one or more of these thunks indeed.

> > 	libgcc/
> > 	* config/mips/mips16.S (DELAYf): Alias to DELAYt for the MIPS IV 
> > 	ISA and up.
> 
> OK, thanks, but please do run it through the testsuite first.

 I'll see if I can do it -- the MIPS/Linux tree I used for recent MIPS32r2 
MADD.fmt testing has no MIPS16 multilibs configured, so it might happen to 
just work with -mips16 passed as an extra option (otherwise MIPS16 libs 
would be automagically picked instead).  I'll check if binaries executeed 
really pulled any of the thunks concerned.

  Maciej