This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: user kprobes vs debuggers


Well come to think of this problem i am thinking this is very similar to the problem between Kprobes and kernel debuggers.
I am thinking we can have a common interface that ptrace and userspace probes can use to register break points similar to the notifiers for kernel probes. The common interface stores the information about all the break points including the ones from the ptrace interface. There is a tag on the breakpoint that specifies whether the breakpoint is inserted by the userspace probes or ptrace. Similar to kernel multiple probe handlers at a probe point, we could have multiple probe handlers for user space probes as well. One of the probe handler among the multiple could be to pass it to the debugger for the probes registered by ptrace. When the break point is hit userspace probes gets the control and checks if there is a userspace probe point at this location, if yes, runs the userspace probes handler and if there is a ptrace registered probe point at the same location pass it debugger as well. Unregistering probes of both types requires updating the global registery of the probe points.


In the above discussion i didn't differentiate between /proc/pid/mem and ptrace() as they both go through the same interface in the kernel they are equivalent for this discussion.

I think this mechanism should handle applications that have breakpoints builtin as well because i am thinking they are going to use ptrace interface as well to register the breakpoint, is that correct.

Did i not consider something in the above design?

Frank Ch. Eigler wrote:

Hi -

During the teleconference earlier today, we discussed the issue of
coexistence of user-mode kprobes (along the favoured #4 path) with
debuggers, manipulating the same tasks.

The core issue is that both systems insert breakpoints into pages
of the target text.  Ideally, we would like both systems to operate
independently, unaware of each other.  But:

Without synchronization over "ownership" of the text pages, two
systems may perform the insertion or removal interleaved in an
inconvenient way.  It may be possible to lose breakpoints, or even to
create spontaneous ones.  To perform sufficient synchronization, we
may need to (a) detect possible conflicts after the fact, (b) bluntly
block one system when the other is active, (c) hook user-kprobes into
ptrace and /proc/mem code paths to intercept debuggers' operations
and/or (d) provide a virtualization facility where the user-space
tools only see a kprobe-less image of the real text page.

A related problem is handling of breakpoints once triggered.  Clearly
user-kprobes get to run first.  The system needs to know whether user
space has also set a breakpoint at the same spot, so a subsequent
ptrace signal can be propagated to the debugger.  Some peculiar
applications may put breakpoints into themselves even without a
debugger present, expecting to catch SIGTRAP.  Ideally, user kprobes
should work with these too.

- FChE






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]