Timo Buhrmester wrote: > 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...''.
Looks like that behavior was introduced by the following commit to src/sys/arch/i386/i386/trap.c: ---------------------------- revision 1.239 date: 2008-05-30 13:38:21 +0300; author: ad; state: Exp; lines: +10 -11; Since breakpoints don't work, dump basic info about the trap before entering the debugger. Sometimes ddb only makes the situation worse. ---------------------------- > Any idea whether a) KGDB is tested/supposed to work and b) what I > might be doing wrong? KGDB over serial on i386 worked for me in January 2008. I don't know if it is still working now; the kernel debugging I've done since then has been using qemu's built-in gdb stub instead, as described in <https://wiki.netbsd.org/kernel_debugging_with_qemu/>. -- Andreas Gustafsson, g...@gson.org