This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Aug 22,  4:02pm, Elena Zannoni wrote:

> 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

Okay, thanks for the explanation.

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

I would prefer that also.

Kevin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]