Re: [RFA] Linux/Sparc patch 3

["David S. Miller" <davem@redhat.com>]

   From: Michael Snyder <msnyder@redhat.com>
   Date: Fri, 19 Apr 2002 18:53:54 -0700

   "David S. Miller" wrote:
   > The child_xfer_memory implementation in infptrace.c is
   > SLOWWWWWWW...  Especially when we have fully functional
   > PTRACE_{READ,WRITE}DATA under Linux/Sparc.
   
   Interesting ... could we benefit from making this
   change on other (perhaps all) linux architectures?
   If so, might it be possible to make the change in
   a single place?
   
Only Linux/Sparc supports PTRACE_{READ,WRITE}DATA, nyah nyah :-)

   > Another bug fix is that we need to make sure all registers
   > are read before store takes place, thus we define
   > CHILD_PREPARE_TO_STORE.  All the BSD'ish Sparc ports set
   > this as well, for the same reason.
   
   Seems perfectly reasonable.  Is this also something
   that should be done for all linuxen?
   
No, it is a Sparc specific issue.  Can I ask you to read my changes
when reviewing them?  I describe the situation precisely in the
comment above this define, and I make it clear that this is a Sparc
specific issue.  If my comment doesn't make this clear, show me how to
make it so. :-)
   
   > We also define PTRACE_*_TYPE in preparation for 64-bit support.
   
   This seems like it could benefit from using multi-arch...

Please wait until the facility to do this is really there.  See my
other emails about OS specific gdbarch init calls 

These values only matter for native ptrace calls anyways, I don't see
why you'd bother multi-arching it.
   
Franks a lot,
David S. Miller
davem@redhat.com