This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



   > 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]