KGDB/i386 broken/supposed to work?

[Timo Buhrmester <fstd.lkml%gmail.com@localhost>]

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