Re: KGDB/i386 broken/supposed to work?

[Andreas Gustafsson <gson%gson.org@localhost>]

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, gson%gson.org@localhost