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

Mark Kettenis
2004-09-20T21:48:11Z

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