Re: [RFA] ppc-linux-nat.c AltiVec regs ptrace

[Kevin Buettner <kevinb@redhat.com>]

On Feb 20,  3:20pm, Elena Zannoni wrote:

> There are 32 vector registers 16 bytes longs, plus a VSCR register
> which is only 4 bytes long, but is fetched as a 16 bytes quantity. Up
> to here we have the elf_vrregset_t structure.
> Appended to this there is space for the VRSAVE register: 4 bytes.
> Even though this vrsave register is not included in the regset
> typedef, it is handled by the ptrace requests.
> 
> The layout is like this:
> 
>  |.|.|.|.|.....|.|.|.|.||.|.|.|x||.|
>  <------->     <-------><-------><->
>    VR0           VR31     VSCR    VRSAVE
> (where x is the actual value of the vscr reg)

Could you add these remarks and this picture as a comment to
ppc-linux-nat.c?  I found it really useful when reviewing parts of the
code.  In particular, I found it useful when looking over the
following function...


> +static void
> +supply_vrregset (gdb_vrregset_t *vrregsetp)
> +{
> +  int i;
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch);
> +  int num_of_vrregs = tdep->ppc_vrsave_regnum - tdep->ppc_vr0_regnum;
> +  int vrregsize = REGISTER_RAW_SIZE (tdep->ppc_vr0_regnum);
> +  int offset = vrregsize - REGISTER_RAW_SIZE (tdep->ppc_vrsave_regnum);
> +
> +  for (i = 0; i < num_of_vrregs - 1; i++)
> +    {
> +      /* The last 2 registers of this set are only 32 bit long, not 128.
> +         However an offset is necessary only for VSCR because it occupies 
> +         a whole vector, while VRSAVE occupies a full 4 bytes slot. */
> +      if (i == (tdep->ppc_vrsave_regnum - 1))
> +        supply_register (tdep->ppc_vr0_regnum + i,
> +                         *vrregsetp + i * vrregsize + offset);
> +      else
> +        supply_register (tdep->ppc_vr0_regnum + i, *vrregsetp + i * vrregsize);
> +    }
> +}

I have a question regarding the treatment of VSCR.  Will the offset
that you computed be correct when running on a little endian machine? 
This may be unanswerable, because it'll likely depend upon what the
ptrace() implementation does.  Therefore, I'm not necessarily
suggesting that you change your patch, but do give it a moment or two of
thought...

Kevin