lkml.org 
[lkml]   [2011]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] Proposal for ptrace improvements
    From
    Date

    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


    \
     
     \ /
      Last update: 2011-03-14 02:07    [W:2.799 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site