Where can I find an analysis of the relative strengths and weaknesses of KDB
and KGDB for kernel debug? Has the linux community come to any consensus
regarding the utility one or the other?
--
Paul J Albrecht
[email protected]
[email protected] said:
> Where can I find an analysis of the relative strengths and weaknesses
> of KDB and KGDB for kernel debug? Has the linux community come to any
> consensus regarding the utility one or the other?
You ought to add UML to the list, since it is useful for debugging any part of
the kernel that's not arch code or a hardware device driver (except that
there's now USB support for UML).
Jeff
On Mon, 30 Apr 2001 16:17:22 -0500,
Paul J Albrecht <[email protected]> wrote:
>Where can I find an analysis of the relative strengths and weaknesses of KDB
>and KGDB for kernel debug? Has the linux community come to any consensus
>regarding the utility one or the other?
kdb is a really low level debugger which understands the kernel
structures. It does its utmost to stop all kernel activity while it is
running and to use as few kernel services as possible so it can run
even when the kernel is dead. It (currently) has no source level
debugging.
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.