More ptrace/hurd questions

[Brent Fulgham <bfulgham@xpsystems.com>]

I've looked a bit deeper into both ltrace's internals
and the Hurd's interface as documented in the
/include, /include/hurd, /include/sys, and /include/mach
header files.  I don't really have a good understanding
of ptrace's interface from these sources, and a look
at similar Linux code does not seem to reveal any
useful parallels.

I attempted to build ltrace to see if it could be
coaxed into doing anything useful.  It does build,
but it dies immediately due to a memory access error.
Stepping through with gdb indicates that this happens
when it attempts to do a 

`ptrace(PTRACE_PEEKTEXT, pid, sbp->addr, 0);`

Where pid and sbp->addr seem to be a valid pid and
memory address, respectively.

This is part of a routine that sets a breakpoint in
the child process (which exec's the program you
are actually interested in ltracing).

I am trying to determine if the problem lies in
the Hurd's implementation of ptrace, or in the
data passed to the ptrace function.

While the Hurd seems to have some manner of
support for ptrace, I don't quite see how it is
implemented.  In Linux, much of this is done in
Kernel space.  The Hurd header file for ptrace
declares it as an extern, and since ltrace did
compile on the Hurd those symbols must be exported
someplace (I assume in one of the hurd servers).

Is there an example of a working program that
makes use of ptrace under the Hurd?

-Brent