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

[Kevin Buettner <kevinb@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