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
Kevin Buettner writes:
> 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...
>
Yes, good idea.
>
> > +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...
>
Yes, I thought about this, I could compute a different offset. But I'll ask
the ptrace implementor...
Is there such a piece of hardware?
I guess I'll add a comment in there, pointing out the endiannes problem.
Elena
> Kevin