> 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.