Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

* Peter Zijlstra <peterz@infradead.org> [2009-11-30 13:41:47]:

> > 
> > This is a In-kernel gdbstub to debug user space programs. 
> > This stub doesnt help in debugging kernel.
> > 
> > Hence I am not sure how to compare kgdb gdbstub with this gdbstub.
> > Can you please provide more pointers on what you were referring to?
> 
> Well, not even that much was clear from your changelog, so I wasn't
> really sure wtf I was looking at. All it says was an in-kernel gdb stub,
> what other than to debug the kernel would you need in-kernel stubs for?
> 
> So now my question is, what do you need an in-kernel stub to debug
> userspace for?
> 

This stub would allow users use features provided by utrace but through
a gdb interface.  This idea was brought up in this year's Tracing
roundtable at the Linux Foundation Collaboration summit, April 8-10 in
San Francisco.  Here is the link to the minutes of the
meeting sent by Christoph Hellwig.
http://www.mail-archive.com/utrace-devel@redhat.com/msg00830.html

> In general, tell me about this patch thing, what does it do, why does it
> do it, and how does it improve on the current situation.

This is suppose to be one of the interfaces to use utrace, i.e Allow
gdb to use utrace features without having to change gdb itself.
Though there are not enough features in this patch, intentions include
support multi-threaded debugging, concurrent debugger support for same
process, syscall tracing.

For Breakpoint support(not yet submitted to LKML), it would use
execution out of line rather than the conventional inline-single
stepping.

I guess Christoph, Roland and Frank would be able to explain in a better
fashion the rational and advantages of this stub over convential gdb.

> 
> Your changelog doesn't address any of those things, so wth are we
> supposed to think?

Thanks for pointing out. 
--
Thanks and Regards
Srikar