[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Proposal for ptrace improvements
    On Tue, 01 Mar 2011 16:24:57 +0100, Tejun Heo wrote:
    > Completion notification is delivered in the usual way via wait(2). If
    > the task was in jctl stop, it would report the stop signal with the
    > matching siginfo. If the task hits an existing ptrace trap condition,
    > the matching SIGTRAP will be reported; otherwise, SIGTRAP will be
    > reported with siginfo indicating PTRACE_SEIZE trap.

    This is a change from the Roland's proposed PTRACE_ATTACH_NOSTOP.
    Currently it is already a problem that apps did not / do not expect the first
    waitpid after PTRACE_ATTACH may not be SIGSTOP. And in the racy case of
    a pending signal during PTRACE_ATTACH which gets delivered by first waidpid
    the tracer either crashes or loses the signal etc. (It was a problem for
    older GDB, it is fixed in recent GDBs, there exist other ptrace using tools.)

    And after all it gets complicated to call PTRACE_ATTACH and then postpone the
    reception of SIGSTOP while other signals are being delivered first.

    > WAY FORWARD (yeah, I'm feeling some marketing vibe)
    > -----------
    > What someone would want if one could start from the scratch is interesting
    > but ultimately irrelevant.

    The ugdb project provides unified debugging facility for both local and remote
    debugging. With the ptrace extensions a network protocol server needs to be
    developed/used anyway and it will be just a thin userland layer mapping
    read/write calls to the ptrace calls on the server side in an ineffective way.

    OTOH one can look at the similar case of TUX/khttpd (also) has never been
    merged into the kernel.


     \ /
      Last update: 2011-03-01 20:09    [W:0.021 / U:37.448 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site