In article <20150619201302.GA243@frozen.localdomain>, Timo Buhrmester <fstd.l...@gmail.com> wrote: >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? >
No, but the explanation is that support for it has probably rotted out. I would file a PR so this information is not lost. christos
