FYI, we have just started work on source level debugging using kdb.
One restriction, it will only work with two machines linked via a
serial line.
One of the design requirements for kdb is that it completely disables
the kernel while you are in kdb. All interrupts are ignored, all cpus
are stopped from doing any work other than kdb. This means all I/O
must be polled, the serial console and keyboard use polling for kdb
I/O. No interrupts means that few, if any, disk controllers will work
while kdb is in control. Also doing disk I/O means using kernel
structures which might be the very structures you are trying to debug.
Or the disk controller might be wedged. So you cannot do I/O to disk
on the machine being debugged.
All is not lost, we are working on this configuration.
Machine 1.
Kernel source tree, compiled with -g.
gdb vmlinux
target remote /dev/ptyxx
/dev/ptyxx is connected to a small C program that talks to gdb on one
side and to the remote machine (via the serial line) on the other.
Machine 2.
Running kernel with kdb.
The C program (tentatively called gdb2kdb) translates gdb packets to
kdb commands and kdb output to gdb packets. You get the benefits of
all the gdb commands (including source level debugging) plus the kdb
kernel specific knowledge. gdb2kdb will have a mechanism for entering
raw kdb commands as well as translating existing gdb commands.
As an example, gdb is very bad at handling kernel back traces. If the
kernel is compiled without frame pointers then gdb basically gives up
on back trace. Even when the kernel is compiled with frame pointers,
not all areas of the kernel use them, so gdb does not always get it
right. kdb bt knows all about the kernel special cases and can do a
decent back trace, even without frame pointers. Instead of using gdb
'bt', you would enter 'kdb bt'.
|