This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: user kprobes vs debuggers
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: "Vara Prasad" <prasadav at us dot ibm dot com>, "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Fri, 3 Feb 2006 09:43:05 -0800
- Subject: RE: user kprobes vs debuggers
Vara Prasad wrote:
> 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.
Who will single-step the original instruction in this scenario? It
seems that the only feasible answer is that the debugger will do it.
But, in the case of a probe inserted sooner than the debugger
breakpoint, the debugger doesn't know the original instruction. And if
the debugger removes its breakpoint, the probe-management would have to
start single-stepping.
Someone mentioned solving this by presenting the debugger with a
virtualized address-space (where the probe doesn't exist). This may be
possible, but in the keep-it-simple spirit I think it would be best to
just reject the second-comer. At least with a common interface we can
detect the conflict, so I think it's fine to just disallow the
situation.
Josh