Re: ptrace(2) autoconf tests

[Mark Kettenis <kettenis@chello.nl>]

   Date: Mon, 09 Aug 2004 09:09:31 -0400
   From: Andrew Cagney <cagney@gnu.org>

   > Anyway, below is a first hack at the autoconf tests.  The tests
   > themselves are inspired by the standard AC_FUNC_CLOSEDIR_VOID and
   > AC_FUNC_SELECT_ARGTYPES tests.  My code defines PTRACE_LONG if the
   > return type of ptrace(2) is `long', defines PTRACE_TYPE_ARG3 to the
   > type of the third argument of ptrace(2) and defines PTRACE_TYPE_ARG5
   > to the type of the fifth argument of ptrace(2) if it has one.
   > PTRACE_TYPE_ARG3 will replace PTRACE_ARG3_TYPE.  PTRACE_XFER_TYPE will
   > be set based on PTRACE_LONG and PTRACE_TYPE_ARG5 will replace
   > FIVE_ARG_PTRACE.

   How should we use this - I'm getting a bit lost with all the macros. 
   Should autoconf define PTRACE_XFER_TYPE (PTRACE_RETURN_TYPE?) directly.

Well, I'm trying to get some consistency.  But having autoconf set
PTRACE_LONG and then define PTRACE_XFER_TYPE based on that, is a bit
silly.  I'll adjust the test and have it set PTRACE_TYPE_RETURN such
that we can use the last one in our code.

   Having this will let us wack a chunk of the nm*.h contents so looking good!

   --

   Hmm, I just noticed call_ptrace() - appears to be something from the HP 
   merge (...).  Perhaphs I should ari the requirement that all ptrace 
   calls are routed through that.  Would let us implement `set debug ptrace!'.

Is that a worthwhile thing to have?  Well, I guess so.  One of things
I'm working on, is a portable "gdb_ptrace.h".  We could simply add a
macro there that takes care of the conversion.

Anyway, given the favourable response, I think I'll just go ahead with
this.

Mark