Re: user kprobes vs debuggers

[Vara Prasad <prasadav@us.ibm.com>]

Stone, Joshua I wrote:

>Vara Prasad wrote:
>  
>
> [...]
>
>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.
>  
>
Let us say if there is no user space probes involved debugger remembers 
the original instruction before replacing it is with breakpoint 
instruction. It single steps the original instruction that is stored in 
the userspace. Let us say if there is no debugger and there is only 
userspace probes userspace pobes does the same single stepping but in 
the kernel space. Another important distinction to remember here is each 
of them have their own handlers to run when the break point is hit.
Based on the above background there is a global registry of the 
breakpoints in the kernel that is only used to notify who all would like 
to handle this breakpoint but it is up to each of the owners to run 
their own handlers and as well as handle single stepping.

One complication in this problems is the applications that have compiled 
breakpoint instructions, but i am not sure how common that occurrence is 
and like i mentioned in my earlier reply we may be able to handle them 
as well.
Does this answer your question?

>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.
>  
>
I think it would have been o.k to disallow but due to common uses like 
strace people might object to userspace probes  feature.

>
>Josh
>
>  
>