Re: user kprobes vs debuggers

[Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>]

On Thu, Feb 02, 2006 at 02:22:31PM -0500, 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.

Just as a datapoint, atleast on PowerPC, kprobes (and xmon) use a
different "BREAKPOINT" opcode from the one used by GDB so, handling most
cases above should be trivial. In fact, we already handle the
possibility that a different debugger/trace tool may have inserted a
breakpoint at a given location (ref: is_trap() in kernel sources).

Breakpoints at the same address in userspace is a more tricky issue
though.

Ananth