[RFC] gelf - user space probe debugger

[RFC] gelf - user space probe debugger

[Jiri Olsa]

hi,

I started a debugger project.  It's based on the user space backport
of optimized kprobes (djprobes) and RSP stub implementation.

The debugger is implemented as a preloaded shared library,
which handles all the debugger work, hence no kernel ptrace
is needed.

It just reached the state where it can handle simple gdb session
of setting/reaching a breakpoint and continue the execution.

Details can be found on http://people.redhat.com/jolsa/gelf/

I'd like to ask for opinions if there'd be users for such thing,
and if it's worth to continue on this..

thanks for any ideas,
jirka


ps. I'm not subscribed to the list, so please include my email
in the answer

Re: [RFC] gelf - user space probe debugger

[Yao Qi]

On 01/25/2011 12:10 AM, Jiri Olsa wrote:
> hi,
> 
> I started a debugger project.  It's based on the user space backport
> of optimized kprobes (djprobes) and RSP stub implementation.
> 

First of all, it is a nice piece of work!

> The debugger is implemented as a preloaded shared library,
> which handles all the debugger work, hence no kernel ptrace
> is needed.

Here are some questions, and I am sorry if my questions go out of scope
here.
1. Do you plan to handle signal without ptrace support?  In
ptrace-debugger, we can know every signal delivered to debuggee process.
 How can we do that in your probe-debugger?

2. Do you plan to support hardware single-step on x86?

> 
> I'd like to ask for opinions if there'd be users for such thing,
> and if it's worth to continue on this..

AFAIK, it is not easy to replace ptrace-based debugger by probe-based
debugger completely.  However, probe-based technology can be a
complementary part to existing ptrace-based debugger, especially to
efficient implementation of breakpoint/watchpoint/tracepoint in some
cases.  Shortly, it is good to put both ptrace-based and probe-based
into single debugger, and maximize their advantages, and minimize their
disadvantages.

-- 
Yao (齐尧)

Re: [RFC] gelf - user space probe debugger

[Jiri Olsa]

On Tue, Jan 25, 2011 at 06:35:40AM +0800, Yao Qi wrote:
> On 01/25/2011 12:10 AM, Jiri Olsa wrote:
> > hi,
> > 
> > I started a debugger project.  It's based on the user space backport
> > of optimized kprobes (djprobes) and RSP stub implementation.
> > 
> 
> First of all, it is a nice piece of work!
> 
thanks

> > The debugger is implemented as a preloaded shared library,
> > which handles all the debugger work, hence no kernel ptrace
> > is needed.
> 
> Here are some questions, and I am sorry if my questions go out of scope
> here.
> 1. Do you plan to handle signal without ptrace support?  In
> ptrace-debugger, we can know every signal delivered to debuggee process.
>  How can we do that in your probe-debugger?

haven't thought about that, but I guess the only option would be to
take over the signal handlers and somehow call the user handlers.. also
intercept the signal handling routines (signal/sigaction..) ..seems tricky ;)

> 
> 2. Do you plan to support hardware single-step on x86?
> 

I haven't thought that far ahead.. looks like it might be possible via
setting the TRAP flag and handling SIGTRAP

> > 
> > I'd like to ask for opinions if there'd be users for such thing,
> > and if it's worth to continue on this..
> 
> AFAIK, it is not easy to replace ptrace-based debugger by probe-based
> debugger completely.  However, probe-based technology can be a
> complementary part to existing ptrace-based debugger, especially to
> efficient implementation of breakpoint/watchpoint/tracepoint in some
> cases.  Shortly, it is good to put both ptrace-based and probe-based
> into single debugger, and maximize their advantages, and minimize their
> disadvantages.

yep, makes sense, I'll think about it.. thanks a lot for feedback

jirka