prototyping linux kernel-side gdbstub for userspace

prototyping linux kernel-side gdbstub for userspace

[Frank Ch. Eigler]

Hi -

I'm slowly assembling a prototype gdb stub for debugging user-space
programs, based on utrace, for possible eventual inclusion in the
linux kernel.  For the moment, it is a toy alternative to ptrace() for
targeting existing processes, and it's not done even for that.  But
before too long though it should be able to use uprobes (q.v.) as a
kernel-side breakpointing facility using the Z packets, and maybe even
support agent expressions, multithreaded processes, and multiprocess
debugging.

Only very basic parts work right now:

% gdb foobar
(gdb) target remote /proc/<pid>/gdb
     (due to suspected utrace bug, must currently manually interrupt the <pid> to get its attention)
#0 ... (backtrace works) ...
#1 ...
(gdb) p expression
# works
(gdb) set expression=value
# appears to work
(gdb) info regs
# appears to work - x86 and x86-64 only
(gdb) continue
# appears to work

But several things don't:
* signal injection
* other architectures
* proper fork/exec handling

Logistically, this is a patch added onto Roland McGrath's utrace git
tree over at git.kernel.org.

   git-clone http://elastic.org/~fche/git/linux-2.6-utrace/

and build enabling CONFIG_UTRACE and CONFIG_UTRACE_GDB.  I'm planning
to continue working on it until the "several things don't" list above
is done.  I'd appreciate any help such as advising, porting, or code
such as on the future extensions listed way above.


- FChE

Re: prototyping linux kernel-side gdbstub for userspace

[Frank Ch. Eigler]

drow wrote:

>> I'm slowly assembling a prototype gdb stub for debugging user-space
>> programs, based on utrace, for possible eventual inclusion in the
>> linux kernel.  [...] But before too long though it should be able
>> to use uprobes (q.v.) as a kernel-side breakpointing facility using
>> the Z packets, and maybe even support agent expressions,
>> multithreaded processes, and multiprocess debugging.

> For those of us with less context, why do it this way instead of
> exposing those features for a userspace gdbserver?

One reason is that these would require extending the kernel ABI,
whether ptrace(2) or something new, and as well extending the
userspace clients.  Doing it across the plain remote protocol means
basically no changes on either end.  This is not to say that the above
can't happen at some point.


> I can't say I'm thrilled to have this in kernel space.

(Of course there is no reason you have to build / run it.)


- FChE

Re: prototyping linux kernel-side gdbstub for userspace

[Daniel Jacobowitz]

On Fri, Jun 19, 2009 at 10:32:04PM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> I'm slowly assembling a prototype gdb stub for debugging user-space
> programs, based on utrace, for possible eventual inclusion in the
> linux kernel.  For the moment, it is a toy alternative to ptrace() for
> targeting existing processes, and it's not done even for that.  But
> before too long though it should be able to use uprobes (q.v.) as a
> kernel-side breakpointing facility using the Z packets, and maybe even
> support agent expressions, multithreaded processes, and multiprocess
> debugging.

Hi Frank,

For those of us with less context, why do it this way instead of
exposing those features for a userspace gdbserver?  I can't say I'm
thrilled to have this in kernel space.

-- 
Daniel Jacobowitz
CodeSourcery