Re: More ptrace/hurd questions
> 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.
You really must be much more specific if you want us to be able to help
you. Give the exact details of the case that fails and show the exact
results, as one always must when reporting any bug in any software. It is
very hard to know what things like "seem to be valid" might mean to any
given person.
> 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.
A trivial test of ptrace(PTRACE_PEEKTEXT,...) works for me, so I cannot
tell without the pertinent details what the nature of the problem might be.
> 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).
As I said before, most traditional interfaces are implemented in libc.
If you are trying to understand the Hurd, then you must look there.
>From the sounds of your confusion, it wouldn't hurt to read some of the
high-level descriptions of the system architecture.
Reply to: