user kprobes vs debuggers

["Frank Ch. Eigler" <fche@redhat.com>]

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