Printing decimal128 types out of registers

[Daniel Jacobowitz]

On Fri, Jan 18, 2008 at 01:42:34PM -0200, Luis Machado wrote:
> -  /* These are the only pseudo-registers we support.  */
> -  gdb_assert (tdep->ppc_ev0_regnum >= 0
> -	      && regnum >= tdep->ppc_ev0_regnum
> -	      && regnum < tdep->ppc_ev0_regnum + 32);
> +  /* These are the e500 pseudo-registers.  */
> +  if (tdep->ppc_ev0_regnum < 0
> +      && regnum < tdep->ppc_ev0_regnum
> +      && regnum >= tdep->ppc_ev0_regnum + 32)
> +    return -1;
> +
> +  /* These are the ppc decimal128 pseudo-registers.  */
> +  if (tdep->ppc_dl0_regnum < 0
> +      && regnum < tdep->ppc_dl0_regnum
> +      && regnum >= tdep->ppc_dl0_regnum + 16)
> +    return -1;

This conversion is wrong - double-check the logic.

> @@ -3380,6 +3492,12 @@
>        else
>  	have_altivec = 0;
>  
> +      feature = tdesc_find_feature (tdesc,
> +				    "org.gnu.gdb.power.dfp128");
> +
> +      if (feature != NULL)
> +	  have_dfp128 = 1;
> +
>        /* On machines supporting the SPE APU, the general-purpose registers
>  	 are 64 bits long.  There are SIMD vector instructions to treat them
>  	 as pairs of floats, but the rest of the instruction set treats them

If the feature is not going to contain anything, I think it should be
a property of the floating point feature rather than an independent
feature - one which says "interpret these FP registers as DFP also",
<property name="dfp-registers"></property> or something similar.

That's how I would handle MMX versus SSE.  However, since there is a
useful software implementation that uses the same registers, Mark is
right - we can just show them all the time.

-- 
Daniel Jacobowitz
CodeSourcery