I'd like to know more about your plans to enhance KDB with source level debug
capability. What sort of compiler debug output would be supported? STABs or
DWARF? Both? What hardware platforms would be supported? What about gui
support?
KDB is console debugger, i.e., it doesn't support a remote serial protocol so
I don't understand how source level debug would work. Would you have to boot
an unstripped kernel executable whenever you wanted to debug?
KGDB is better because it's a source level debugger and because you get a
graphical interface, Data Display Debugger (DDD), for free when you use gdb.
KGDB is better because it's more platform agnostic than KDB. The only
architecture dependent part in the kernel is the gdb stub which is small and
well defined.
> 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.
>
I don't know what you mean when you say "loose knowledge of kernel internals"
with KGDB ... I'd rather develop a set of standard gdb user defined commands to
expose kernel internals than hard code them in the linux kernel.
As for stack frame analysis, both debuggers have problems with backtrace if the
kernel is compiled without CONFIG_FRAME_POINTER option. Whether the problem is
fixed in gdb for KGDB users or the kernel for KDB users is immaterial in
choosing one debugger over the other.
-- Paul J Albrecht pjalbrecht@home.com - 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/