This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] rs6000-tdep.c: more e500 support
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Elena Zannoni <ezannoni at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Thu, 22 Aug 2002 11:48:53 -0700
- Subject: Re: [RFA] rs6000-tdep.c: more e500 support
- References: <15717.9340.349019.324586@localhost.redhat.com>
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?
> @@ -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.)
Kevin