lkml.org 
[lkml]   [2001]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux Kernel Debuggers, KDB or KGDB?
Date
On Tue, 01 May 2001 11:16:50 +1000, Keith Owens <kaos@ocs.com.au> wrote:
>kgdb relies on gdb so you loose the knowledge of kernel internals (no,
>I am *not* going to teach gdb about kernel stacks, out of line lock
>code etc.). kgdb has more of a dependency on a working kernel. It
>provides source level debugging, although stack backtrace tends not to
>work unless you compile the kernel with frame pointers.
>
>UML is great for debugging generic kernel code such as filesystems, but
>cannot be used for most arch code or hardware drivers.
>
>My ideal debugger is one that combines the internal knowledge of kdb
>with the source level debugging of gdb. I know how to do this over a
>serial line, finding time to write the code is the problem.

I've been thinking about this a little bit and I suspect the right thing
may be to combine a kgdb style debuging stub with the Mission Critical
Linux crash code (http://oss.missioncriticallinux.com/projects/crash/).
Crash is based around gdb and adds the ability to easily examine the
process table, memory maps, kernel logs, wait queues, timers, etc. Crash
already is able to examine a live system by reading /dev/mem. The only
thing you'd need to add is the ability to attach to a live system over a
serial port (probably not too hard since gdb already knows how to do that).

Aaron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.024 / U:2.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site