I'm failing to get KGDB on i386 working for kernel debugging over a serial (nullmodem) link, as described in http://www.netbsd.org/docs/kernel/kgdb.html
The TARGET (to-be-debugged) system has two serial ports, com0 is the boot console, com1 is what I set KGDB to operate on. The REMOTE (debugger) system uses its com0 port to connect to the target's com1. Using a GENERIC kernel with only the modifications required to enable KGDB (see bottom for config diff), I get the following behavior on the TARGET machine: | > boot netbsd -d | 15741968+590492+466076 [689568+730405]=0x1161fd4 | kernel text is mapped with 4 large pages and 5 normal pages | Loaded initial symtab at 0xc110750c, strtab at 0xc11afaac, # entries 43075 | kgdb waiting...fatal breakpoint trap in supervisor mode | trap type 1 code 0 eip c02a6744 cs 8 eflags 202 cr2 0 ilevel 8 esp c1265ea0 | curlwp 0xc1078900 pid 0 lid 1 lowest kstack 0xc12632c0 There is no delay between ``kgdb waiting...'' and ``fatal breakpoint trap in supervisor mode''. I'm not sure whether or not this is the expected behavior, because eip c02a6744 is in the `breakpoint` function so that would make sense; but the documentation makes it sound like it should just say ``kgdb waiting...''. On the REMOTE (debugger) machine (serial port tty00) I get/do: | # gdb -q netbsd.gdb | Reading symbols from netbsd.gdb...done. | (gdb) set remotebaud 38400 | Warning: command 'set remotebaud' is deprecated. | Use 'set serial baud'. | | (gdb) set serial baud 38400 | (gdb) set remotebreak 1 | Warning: command 'set remotebreak' is deprecated. | Use 'set remote interrupt-sequence'. | | (gdb) set remote interrupt-sequence Ctrl-C | (gdb) set remotetimeout 5 | (gdb) target remote /dev/tty00 | Remote debugging using /dev/tty00 | Ignoring packet error, continuing... | warning: unrecognized item "timeout" in "qSupported" response | Ignoring packet error, continuing... | Ignoring packet error, continuing... | Bogus trace status reply from target: timeout | (gdb) ..which I presume is due to the target already having ceased execution. Both machines run the same, recent -current build (7.99.18) on i386. I have verified that the serial connection works in both directions, using a non-KGDB GENERIC kernel. I have also verified that kgdb is actually in the kernel and using the right port (com1) when booting the KGDB kernel without -d: | com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo | com0: console | com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo | com1: kgdb The difference between GENERIC and my KGDB-enabled version of it: -#options DEBUG # expensive debugging checks/support +options DEBUG # expensive debugging checks/support #options LOCKDEBUG # expensive locking checks/support #options KMEMSTATS # kernel memory statistics (vmstat -m) -options DDB # in-kernel debugger +#options DDB # in-kernel debugger #options DDB_ONPANIC=1 # see also sysctl(7): `ddb.onpanic' -options DDB_HISTORY_SIZE=512 # enable history editing in DDB +#options DDB_HISTORY_SIZE=512 # enable history editing in DDB #options DDB_VERBOSE_HELP -#options KGDB # remote debugger -#options KGDB_DEVNAME="\"com\"",KGDB_DEVADDR=0x3f8,KGDB_DEVRATE=9600 -#makeoptions DEBUG="-g" # compile full symbol table +options KGDB # remote debugger +options KGDB_DEVNAME="\"com\"",KGDB_DEVADDR=0x2f8,KGDB_DEVRATE=38400 +makeoptions DEBUG="-g" # compile full symbol table #options SYSCALL_STATS # per syscall counts #options SYSCALL_TIMES # per syscall times #options SYSCALL_TIMES_HASCOUNTER # use 'broken' rdtsc (soekris) Any idea whether a) KGDB is tested/supposed to work and b) what I might be doing wrong? Is there any other relevant information I missed that would be useful to provide? Timo Buhrmester
