Messages in this thread | | | Date | Fri, 24 Dec 1999 23:26:10 +0100 | From | Pavel Machek <> | Subject | Re: CLONE_PTRACE implementation incomplete |
| |
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/
| |