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
On Wed, Feb 20, 2002 at 04:06:56PM -0500, Elena Zannoni wrote:
> Right will fix. [I had an ongoing bet :-)]
What, whether Andrew would get to you before I did? :)
<duck and run>
> > > +int have_ptrace_getvrregs
> > > +#ifdef HAVE_PTRACE_GETFPXREGS
> > > + = 1;
> > > +#else
> > > + = 0;
> > > +#endif
> > > +
> >
> > Huh? You defined GETVRREGS unconditionally above. GETFPXREGS has no
> > place in this file, does it? Or do the headers define GETFPXREGS?
> > You also continue this confusion all the way down the patch.
> >
>
> The glibc headers define GETFPXREGS, and that's what we test for in
> the configury. But we are not dealing with floating point registers
> here, so I used the 'correct' name where I could. It would be more
> confusing to talk about FPX regs while instead there are none.
> I explained this in the comments.
>
> I guess I can do the following if it helps.
> #ifdef HAVE_PTRACE_GETFPXREGS
> #define HAVE_PTRACE_GETVRREGS
>
> Whatever I end up using it's partially going to be a lie. I would
> prefer using the VRREGS nomenclature where relevant, though.
I'm confused.
On i386, glibc defines PTRACE_GETFPXREGS. On PowerPC, in current FSF
glibc, sys/ptrace.h does not define anything along these lines at all.
The kernel <asm/ptrace.h> define GETVRREGS (not that we should be
including that header, of course). [<sys/ptrace.h> is an
architecture-specific header, which may not have been apparent.]
If there are outstanding patches to glibc, which defines
PTRACE_GETFPXREGS on PowerPC, then they are still mutable. They should
be updated to a reasonable value.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer