Re: [RFC] Proposal for ptrace improvements

[Frank Ch. Eigler]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/