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

Mark Kettenis
2004-09-24T22:37:55Z

Date: Tue, 21 Sep 2004 09:07:28 -0400
From: Andrew Cagney <cagney@gnu.org>

I committed the patch:

2004-09-24 Mark Kettenis <kettenis@gnu.org>

* inf-ptrace.c (inf_ptrace_kill_inferior): Call ptrace directly
instead of call_ptrace. Call wait directly instead of
ptrace_wait.
(inf_ptrace_me): Call ptrace directly instead of call_ptrace.
(inf_ptrace_wait): Inline ptrace_wait call.

But this doesn't mean we shouldn't continue this discussion. It
actually makes things easier for us whatever the outcome because now
we can forget about replacing call_ptrace, and can just focus on
ptrace(). Please read on.

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

The problem here is that the third argument of ptrace is used for two
purposes:

1. For specifying memory addresses of objects in the debugger's
address space (PT_GETREGS, PT_SETREGS, PT_IO).

2. For specifying memory addresses in the inferior.

This gets especially complicated with 32x64 "native" cross-debugging
and is further complicated by the fact that some systems use an
integer type and other systems use a pointer type for this third
arguments. I've tried to come up with a function signature for
gdb_ptrace() that would work for all targets, and I failed.

Mark