Reading the linux kernel documentation on KGDB wasn’t enough for me to be able
\nto use the newly built-in KGDB kernel debugger with version 2.6.26 or 2.6.27.
\nThe breakthrough for me was reading [part of Jason Wessel’s
\nguide](http:\/\/www.kernel.org\/pub\/linux\/kernel\/people\/jwessel\/kgdb\/ch03s03.html).<\/p>\n
I have two machines:<\/p>\n
* developer – where I run gdb
\n* target – where the kernel is being debugged, running in VMware<\/p>\n
Configure VMware on the developer machine<\/p>\n
* Power down the guest (target)
\n* Edit the VM guest settings
\n* Add a serial port
\n * Use named pipe `\/tmp\/com_1` (it’s really a UNIX domain socket)
\n * Configure it to “Yield CPU on poll” (under Advanced)
\n* Install ‘socat’, if not already installed<\/p>\n
Configure and Compile the kernel on the developer or the target machine<\/p>\n
– Get kernel 2.6.26 or newer
\n– `make menuconfig` # or make gconfig
\n– Under Kernel Hacking:
\n – enable KGDB
\n – enable the Magic SysRq key
\n – enable “Compile the kernel with debug info”
\n– Build kernel: `make`<\/p>\n
Configure target<\/p>\n
– Enable Magic SysRq key on target:
\n – Edit \/etc\/sysctl.conf and set `kernel.sysrq = 1`
\n – or run `sysctl -w kernel.sysrq=1` # this doesn’t survive a reboot
\n– Install developer kernel
\n – On the developer machine:
\n `rsync -av –exclude .git .\/ root@target.host.name:\/mnt\/work\/linux-2.6.26`
\n – On the target, a RedHat based system:
\n `make install`
\n `make modules_install`
\n– Edit \/boot\/grub\/grub.conf and set `timeout=15`
\n– Boot into the newly installed kernel<\/p>\n
Start debugging<\/p>\n
– On target:
\n `echo ttyS0 > \/sys\/module\/kgdboc\/parameters\/kgdboc`
\n– On developer:
\n `socat -d -d \/tmp\/com_1 PTY:` # notice what pty is allocated — \/dev\/pts\/1 in my case
\n `gdb vmlinux`
\n `set remotebaud 115200`
\n `target remote \/dev\/pts\/1`
\n– On target, do one of the following:
\n – `echo “g” > \/proc\/sysrq-trigger`
\n – Type ALT-SysRq-G
\n– Ready, get set, go! Go back to developer machine and use gdb to set
\n breakpoints, continue, etc.<\/p>\n
I set up debugging because I wanted to understand the behavior of the kernel
\nwhen loading a module. It turns out that loading of the module failed because
\nsitting in a debugger delayed the execution, causing a timeout in module load
\nby the time I stepped through the code. Use of printk turned out to work
\nbetter.<\/p>\n","protected":false},"excerpt":{"rendered":"
Reading the linux kernel documentation on KGDB wasn’t enough for me to be able to use the newly built-in KGDB kernel debugger with version 2.6.26 or 2.6.27. The breakthrough for me was reading [part of Jason Wessel’s guide](http:\/\/www.kernel.org\/pub\/linux\/kernel\/people\/jwessel\/kgdb\/ch03s03.html). I have two machines: * developer – where I run gdb * target – where the kernel … <\/p>\n