[RFA] rs6000-tdep.c: more e500 support
Kevin Buettner
kevinb@redhat.com
Thu Aug 22 13:41:00 GMT 2002
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
More information about the Gdb-patches
mailing list