This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] ppc-linux-nat.c AltiVec regs ptrace
- 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, 21 Feb 2002 08:32:40 -0700
- Subject: Re: [RFA] ppc-linux-nat.c AltiVec regs ptrace
- References: <15476.1308.919907.110811@localhost.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