Re: user kprobes vs debuggers

[Richard J Moore <richardj_moore@uk.ibm.com>]

I honestly think the simplest and only possible general solution is not to
allow or support a probe to be placed on any pre-existing breakpoint.

The problem we have in general is that we cannot say what the expected
outcome of a breakpoint should be.

In some cases it will be to terminate the program i.e. exit to system.
In others it will be to enter a debugger with the option of resuming at the
same or some other point or indeed exiting.
In the case of a probepoint, which is more than a mere breakpoint, the
processing is complex and automated.


Concerns about who handles the debug exception (IA32) apply also to who
handles or intercepts any exception generated by a given instruction.

To support multiple uses of a breakpoint we would need to establish a
protocol that all users would adhere to and a set of APIs to support all
users and multiple concurrent users of APIs. Unless someone can point to a
real need to multi-user breakpoints I suggest we shelve this with the
caveat that probes placed on breakpoints and breakpoints placed on probes
are not supported. We can protect ourself from trouble by putting a test in
kprobes (1) on probe insertion to make sure that we don't install a probe
on a breakpoint and possibly (2) at single-step to make sure that we don't
SS a breakpoint. ptrace should probably make a similar test on breakpoint
insertion.

- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072

systemtap-owner@sourceware.org wrote on 06/02/2006 09:58:35:

> 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