Re: [RFA/RFC] Replace call_ptrace and ptrace_wait in inf-ptrace.c

[Mark Kettenis <kettenis@gnu.org>]

   Date: Mon, 20 Sep 2004 15:34:41 -0400
   From: Andrew Cagney <cagney@gnu.org>

   > This is another step in the direction of eliminating the need for both
   > inf-ptrace.c and infptrace.c.  It eliminates the calls to call_ptrace
   > and ptrace_wait.
   > 
   > Andrew has recently suggested that we'd want debugging support for the
   > ptrace(2) interface, which could be implemented by using call_ptrace()
   > unconditionally.

   Having, again, spent some time debugging GNU/Linux threads, I'm pretty 
   much certain of this.

   > That, however, is a bad idea, since this makes it
   > impossible for the compiler to properly typecheck the arguments to
   > ptrace().

   How so?

The variety in ptrace(2) prototypes is pretty big.  Arguments can be
integer or pointer types of various sizes (32-bit, 64-bit).  We simply
cannot get that right for all supported operating systems.  So we have
to guess.  Being conservative, we use a long integer type, say
CORE_ADDR, for the n-th argument of call_ptrace().  Suppose that on an
LP64 platform we pass, by mistake, a pointer as the n-th argument of
ptrace, but that argument should really be an int.  Because of the
intermediate call_ptrace() the compiler doesn't warn us about it.  The
result is probably a mysterious bug.

If we'd used a macro instead, the compiler would have warned us.

   I've noticed that ptrace can sometimes be declared with a variable 
   number of arguments, but that just suggests there should be a 
   gdb_ptrace4() and gdb_ptrace5() with explicitly 4 and 5 arguments.

Linux does variable number of arguments, although the underlying
system call isn't.  I believe the 5-arg SunOS-compatible
PTRACE_READDATA on SPARC Linux simply doesn't work.

We shouldn't need an explicit 5-arg ptrace.  The fifth argument is
always zero in GDB.

Mark