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
