[RFA] rs6000-tdep.c: more e500 support

[Elena Zannoni]

Kevin Buettner writes:
 > On Aug 22,  1:50pm, Elena Zannoni wrote:
 > 
 > > @@ -647,7 +654,7 @@ skip_prologue (CORE_ADDR pc, CORE_ADDR l
 > >        else if ((op & 0xfc0007fe) == 0x7c000378 &&	/* mr(.)  Rx,Ry */
 > >                 (((op >> 21) & 31) >= 3) &&              /* R3 >= Ry >= R10 */
 > >                 (((op >> 21) & 31) <= 10) &&
 > > -               (((op >> 16) & 31) >= fdata->saved_gpr)) /* Rx: local var reg */
 > > +               ((long) ((op >> 16) & 31) >= fdata->saved_gpr)) /* Rx: local var reg */
 > >  	{
 > >  	  continue;
 > >  
 > 
 > Why is the cast needed above?

Signed & unsigend comparisons, when saved_gpr is -1:
op is unsigned long, while saved_gpr is an int

I was running into this:
(gdb) p (unsigned long) 0 > (int) -1
$3 = 0

the cast makes it work. I could have changed the type of op, but I was
afraid I would break a bunch of other things.

(gdb) p (long) 0 > (int) -1
$4 = 1


 > 
 > > @@ -754,6 +763,100 @@ skip_prologue (CORE_ADDR pc, CORE_ADDR l
 > >  	    }
 > >  	}
 > >        /* End AltiVec related instructions.  */
 > > +
 > > +      /* Start BookE related instructions.  */
 > > +      /* Store gen register S at (r31+uimm).
 > > +         Any register less than r13 is volatile, so we don't care.  */
 > > +      /* 000100 sssss 11111 iiiii 01100100001 */
 > > +      else if ((op & 0xfc1f07ff) == 0x101f0321)     /* evstdd Rs,uimm(R31) */
 > 
 > Hmm... it looks like BookE is using 6 for its primary opcode (which are
 > the most significant 6 bits).  I wonder if this could cause conflicts
 > with other cores which also extend the base PPC instruction set.
 > 
 > A quick Google search reveals:
 > 
 >     http://sources.redhat.com/ml/binutils/2001-10/msg00186.html
 > 
 > So apparently there can be conflicts.  It's not clear to me if there
 > are conflicts for the instructions that we care about, but I wonder
 > if it might not be better to add a conjunct which restricts these tests
 > to the BookE architecture.  (Maybe it'd be a good idea to squirrel
 > away the v->arch and v->mach values from rs6000_gdbarch_init() into
 > the gdbarch_tdep struct.  I guess you could also check to see if
 > tdep->ppc_ev0_regnum is not -1.)
 > 

Yes, conflicts also with Altivec instructions. I would prefer to save
the architecture & machine pair, rather than check the registers.

Elena


 > Kevin