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

Andrew Cagney
2004-09-21T13:09:55Z

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

Either way we'll end up with casts:
CORE_ADDR -> (void *)
(void *) -> long
etc, why not have methods that at least avoid the casts (or do it
locally to GDB's ptrace code?).

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

good news
Andrew