|
After i apply the KGDB patches to kernel, complie
and boot with the new image, my machine appears to hang up. Whats wrong?
KGDB for Linux 2.6.8-rc1 onwards uses early_param to pass the control
to KGDB code in the kernel during the bootup. This is done very early
in the kernel boot up before any messages can be enabled. Hence during
the boot up the kernel is actually waiting for connection from remote
GDB but since it cannot display any messages it appears that the
machine has hung.
Why are two machines necessary for KGDB?
KGDB requires gdb for handling source code and debug information
generated by gcc. gdb cannot be run on the test machine when the kernel
is in debug state. Hence gdb has to be run on a separate machine which
contains a running kernel.
Can I place breakpoints in interrupt handlers?
Yes, you can. Breakpoints can be placed almost anywhere in a kernel.
KGDB cannot handle breakpoints only in the parts of the kernel which
are used by it (KGDB). These include the KGDB serial line handler and
interprocessor interrupt handlers.
Why does a kernel and modules need to be compiled on
a developement machine instead of a test machine?
gdb needs to refer to source code files and vmlinux or a module object
file. Since gdb runs on the developement machine, these files are
required to be present on the developement machine. The test machine
needs vmlinuz or module object files only. If a kernel or modules are
compiled on the developement machine, only vmlinuz or module object
files need to be copied to the test machine. On the other hand,
compiling a kernel or modules on the test machine makes it it necessary
to copy object files as well as source code files to the developement
machine. Hence a developement model is much simplified if compilation
is done on a developement machine.
Why do I need to compile all kernel drivers except
for the one to be debugged in the kernel and not as modules?
In the current module debugging model, a module has to be loaded by a
script. Drivers compiled in the kernel are loaded automatically during
bootup. Since gdb does not know about those modules, if control goes to
any code within the module, gdb won’t be able to print line numbers,
stack trace etc. If modules are needed, then should be loaded by loadmodule.sh
script.
KGDB stub as well as gdb will need to be modified to fix the problem. A
gdb fix for a similar problem in userland is under implementation
(First patch to fix gdb appeared in July 2001). Once gdb is fixed, I’ll
fix KGDB stub. After that a special script will not be needed to load
modules. gdb will automatically recognize all modules loaded in the
kernel.
I am working on the problem. Both gdb and KGDB stub fixes are
non-trivial and will take some time (Around October 2001). If you need
a fix for this problem ealier than that, please send me a mail. If many
people want the fix, I’ll work faster and release a not-so-complete
version.
I am not able to debug my modules …
For module debugging the appropriate GDB should be used on the
development machine. Please see the module
debugging page for more details.
|