The following reply was made to PR toolchain/35118; it has been noted by GNATS.

From: Paul Ripke <stix@stix.id.au>
To: Christos Zoulas <christos@astron.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: toolchain/35118 gdb6 "bt" fails on kernel dumps
Date: Thu, 30 Nov 2006 21:35:36 +1100

 Hi Christos,
 
 Sorry about the delay in testing further... After your updates to gdb6:
 
 http://mail-index.netbsd.org/source-changes/2006/11/26/0013.html
 
 I've re-tested on a new dump, and it appears gdb can now trace back
 up to the first trap. eg:
 
 (gdb) bt
 #0  0xc0618000 in ?? ()
 #1  0xc0319242 in dumpsys () at /export/netbsd/current/src/sys/arch/i386/i386/machdep.c:1158
 #2  0xc0319368 in cpu_reboot (howto=260, bootstr=0x0) at /export/netbsd/current/src/sys/arch/i386/i386/machdep.c:869
 #3  0xc015afe8 in db_reboot_cmd (addr=-1071435613, have_addr=0, count=-1069376627, 
     modif=0xcb4d544c "\213\233BÀ\214\233BÀ4") at /export/netbsd/current/src/sys/ddb/db_command.c:762
 #4  0xc015ab80 in db_command (last_cmdp=0xc041cadc, cmd_table=0x0)
     at /export/netbsd/current/src/sys/ddb/db_command.c:507
 #5  0xc015af45 in db_command_loop () at /export/netbsd/current/src/sys/ddb/db_command.c:295
 #6  0xc015dd69 in db_trap (type=6, code=0) at /export/netbsd/current/src/sys/ddb/db_trap.c:101
 #7  0xc0315382 in kdb_trap (type=6, code=0, regs=0xcb4d5674)
     at /export/netbsd/current/src/sys/arch/i386/i386/db_interface.c:226
 #8  0xc032474e in trap (frame=0xcb4d5674) at /export/netbsd/current/src/sys/arch/i386/i386/trap.c:313
 #9  0xc010c01a in calltrap ()
 #10 0xcb4d5674 in ?? ()
 #11 0x00000010 in ?? ()
 #12 0xcb4d0030 in ?? ()
 #13 0xcb460010 in ?? ()
 #14 0x00000010 in ?? ()
 #15 0xcb380560 in ?? ()
 #16 0x00000000 in ?? ()
 
 Whereas, ddb, on the same dump, gives:
 
 kernel: supervisor trap page fault, code=0
 Stopped in pid 892.1 (find) at netbsd:lfs_putpages+0x3e3 movl %eax,0(%edx)
 db{1}> bt
 lfs_putpages(cb4d5780,1,0,c03b1060,cb380560) at netbsd:lfs_putpages+0x3e3
 VOP_PUTPAGES(cb380560,0,0,0,0) at netbsd:VOP_PUTPAGES+0x40
 vinvalbuf(cb380560,1,ffffffff,cb32781c,0) at netbsd:vinvalbuf+0x4f
 vclean(cb088868,800,0,37c,1) at netbsd:vclean+0x1d4
 vgonel(cb380560,cb32781c,2,c02d5a58,c09a601c) at netbsd:vgonel+0x55
 getcleanvnode(c09a6000,200000,0,ffffffff,cb4d5958) at netbsd:getcleanvnode+0xcf
 getnewvnode(5,c09a6000,c089a500,cb4d5954,0) at netbsd:getnewvnode+0xba
 lfs_vget(c09a6000,4a9,0,cb4d5a34,cb4d5a38) at netbsd:lfs_vget+0x12f
 ufs_lookup(cb4d5a5c,1,c03b0660,cb088868,cb4d5bd8) at netbsd:ufs_lookup+0x93d
 VOP_LOOKUP(cb088868,cb4d5bd8,cb4d5bec,c02e44a8,cb55e604) at netbsd:VOP_LOOKUP+0x2b
 lookup(cb4d5bc8,ca2d3c00,400,cb4d5be0,0) at netbsd:lookup+0x28a
 namei(cb4d5bc8,805ad58,64,c024cd0d,1306) at netbsd:namei+0x11a
 sys___lstat30(cb32781c,cb4d5c4b,cb4d5c68,805a048,805a000) at netbsd:sys___lstat30+0x46
 syscall_plain() at netbsd:syscall_plain+0x198
 --- syscall (number 389) ---
 0xbbbaa0f7:
 db{1}> 
 
 So, while looking quite a bit better, it's not quite there.
 
 --
 stix