[lkml]   [1999]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: CLONE_PTRACE implementation incomplete

> > 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?
I'm "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.046 / U:6.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site