Re: Linux Kernel Debuggers, KDB or KGDB?
On Tue, 01 May 2001 11:16:50 +1000, Keith Owens <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel Debuggers, KDB or KGDB?
On Tue, 01 May 2001 11:16:50 +1000, Keith Owens [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
