Messages in this thread | | | Subject | Re: [RFC] Proposal for ptrace improvements | From | (Frank Ch. Eigler) | Date | Sun, 13 Mar 2011 21:03:57 -0400 |
| |
Hi -
tj wrote:
> [...] >> I've said before more than once what I think are the important >> principles about compatibility that ought to be maintained [...] > The biggest changes the current ptrace users are gonna see are > probably the ones from P1 and those are really corner cases - /proc > state, behavior change visible only to other thread in a multithreaded > debugger [...] > Also, ptrace is inherently a very heavy mechanism. [...] > If someone is looking for completely transparent light weight > monitoring [look elsewhere...] > I skipped a lot of parts but in general I think that you're trying > to do too much with ptrace. ptrace has its place which is called > debugging. [...]
Take care not to define your problems away by something close to a false dichotomy: intrusive ptrace vs. transparent tracing. One needs transparent enough debugging too, so that the presence of the debugger does not subvert the occurrence of complex or transient phenomena. This hazard is especially acute for multithreaded programs. While ptrace is known to be an imperfect substrate for multithreaded debugging, it would be nice not to make it any worse.
Note that I'm not claiming that your current proposals necessarily would do so, but the argument for treating ptrace as machinery appropriate only for "heavy-weight diddling" could lead that way.
- FChE
| |