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

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > On Wed, Feb 20, 2002 at 06:06:55PM -0500, Elena Zannoni wrote:
 > > Daniel Jacobowitz writes:
 > >  > I'm confused.
 > > 
 > > Yeah, you are not the only one.
 > > 
 > >  > 
 > >  > On i386, glibc defines PTRACE_GETFPXREGS.  On PowerPC, in current FSF
 > >  > glibc, sys/ptrace.h does not define anything along these lines at all. 
 > > 
 > > OK, I have downloaded glibc 2.2.5, and sysdeps/unix/sysv/linux/sys/ptrace.h
 > > defines PTRACE_GETFPXREGS.
 > > 
 > > Then on my system, I have /usr/include/sys/ptrace.h which also defines it.
 > > But I think I have an older version of glibc installed.
 > > 
 > > What I am not understanding is where the installed file comes from, is
 > > it the same as sysdeps/unix/sysv/linux/sys/ptrace.h?
 > 
 > The way the glibc build process works is a mess.  Every target has a
 > list of sysdep directories.  The first matching file is installed.  In
 > this case, it is sysdeps/unix/sysv/linux/powerpc/sys/ptrace.h.  When
 > looking for a file in the glibc source, I recommend always getting a
 > list of all files by that name first.
 > 

Ohhh, thanks!

Ok, now I understand where the file comes from.

I have glibc-2.2.1 installed:
$ find . -name ptrace.h
./sysdeps/generic/sys/ptrace.h
./sysdeps/unix/sysv/linux/alpha/alpha/ptrace.h
./sysdeps/unix/sysv/linux/s390/sys/ptrace.h
./sysdeps/unix/sysv/linux/sparc/sys/ptrace.h
./sysdeps/unix/sysv/linux/sys/ptrace.h


While in the 2.2.5 sources:
$ !find
find . -name ptrace.h
./sysdeps/generic/sys/ptrace.h
./sysdeps/unix/sysv/linux/alpha/alpha/ptrace.h
./sysdeps/unix/sysv/linux/ia64/sys/ptrace.h
./sysdeps/unix/sysv/linux/powerpc/sys/ptrace.h
./sysdeps/unix/sysv/linux/s390/sys/ptrace.h
./sysdeps/unix/sysv/linux/sparc/sys/ptrace.h
./sysdeps/unix/sysv/linux/sys/ptrace.h


In case of 2.2.5 the powerpc version of the file gets installed. While
for 2.2.1 the one with the definitions for PTRACE_GETFPXREGS is installed.

Ok then, should we support the older version or not?
If not we have two options:

1. if glibc gets a patch with the new PTRACE_GETVRREGS requests, then
   we can add another different configuration check.

2. We can just rely on the run time check. Which means I have to redo
   the patch again [where is that bucket].

Actually doing just 2 would work also with the older version, I guess.
Unless I am missing some other subtlety. Ok I'll change it.

Elena