Re: CLONE_PTRACE implementation incomplete

Pavel Machek (pavel@suse.cz)
Fri, 24 Dec 1999 23:26:10 +0100


Hi!

> > IIRC, Linus has already claimed once that he doesn't very much like the
> > whole reparenting mess introduced for debugging. He said that instead of
> > fixing some other bugs in this code, ptrace should be fixed so the ppid of
> > a process isn't changed just because it's being debugged. (Actually, he
> > proposed that the connection between debugger and debuggee shouldn't be
> > made using the p_pptr field, but through another specific field; I believe
> > this is even quite easy to achieve, as it's very similar to the CLONE_WAIT
> > flag's implementation...)
> >
> > So, if this is fixed, CLONE_PTRACE can truly become standalone (it will
> > just copy the new p_dbptr field)...
> >
> > Any takers? (I can only start on this when I have my new comp, which will
> > take a few more weeks...)
>
>
> I've thought about doing something like this. I'd really, really, really like
> to have some way to trace processes without the Heisenberg effect. Because of
> the reparenting games it plays, ptrace messes up the semantics of the
> interaction between a traced process and its parent. These alterations
> greatly limit the usefulness of ptrace. In a proper solution, any changes
> should be absolutely minimal (e.g., if a process watched itself carefully, it
> might notice that system calls run slower while it's being traced).

BTW do you know that with current strace, task can actually do _other_
syscalls than you see with ptrace() interface?
Pavel

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/