RE: user kprobes vs debuggers

["Stone, Joshua I" <joshua.i.stone@intel.com>]

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