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

[Elena Zannoni <ezannoni at redhat dot com>]

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