Re: gdb-6 in 5.3-BETA3

On Monday,  6 September 2004 at 10:46:43 +0400, Boris B. Samorodov wrote:
> On Sun, Sep 05, 2004 at 11:31:52PM -0700, John-Mark Gurney wrote:
>
>> Boris B. Samorodov wrote this message on Mon, Sep 06, 2004 at 10:31 +0400:
>>> New gdb V.6 in base system doesn't have option '-k', while the ports's
>>> version has. Is it planned to be fixed till 5.3-RELEASE?
>>
>> but there is kgdb....
>
> OK. kgdb works fine.
>
> But it is not clear from "man gdb", that if option "gdb -k" is not
> working, one should use "kgdb".

Indeed.  I thought that kgdb was deprecated, and that we should be
using gdb -k.  It would be nice to come to an agreement on that.

Note also that most recent versions of gdb seem to be broken when
trying to access userland.  On a machine built in May:

  GNU gdb 5.2.1 (FreeBSD)
  (kgdb) f 16
  #16 0xc0621df8 in namei (ndp=0xd7c05c30) at /usr/src/sys/kern/vfs_lookup.c:179
  179                     error = lookup(ndp);
  (kgdb) p *ndp
  $1 = {
    ni_dirp = 0x805f8a8---Can't read userspace from dump, or kernel process---

Same dump with recently ported gdb6.  Backtrace contains many spurious
"stack frames":

  GNU gdb 20040803 [GDB v6.x for FreeBSD]
  (partial bt)
  #6  0xc074c67c in trap (frame=
        {tf_fs = 0x18, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0xc07ba264, tf_esi = 0x1, tf_ebp = 0xd7c05964, tf_isp = 0xd7c0594c, tf_ebx = 0x0, tf_edx = 0x0, tf_ecx = 0xc1014000, tf_eax = 0x12, tf_trapno = 0x3, tf_err = 0x0, tf_eip = 0xc073a4de, tf_cs = 0x8, tf_eflags = 0x296, tf_esp = 0xd7c05998, tf_ss = 0xd7c05984}) at /usr/src/sys/i386/i386/trap.c:579
  #7  0xc073b7ca in calltrap () at {standard input}:94
  #8  0x00000018 in ?? ()
  #9  0x00000010 in ?? ()
  #10 0x00000010 in ?? ()
  #11 0xc07ba264 in ?? ()
  #12 0x00000001 in ?? ()
  #13 0xd7c05964 in ?? ()
  #14 0xd7c0594c in ?? ()
  #15 0x00000000 in ?? ()
  #16 0x00000000 in ?? ()
  #17 0xc1014000 in ?? ()
  #18 0x00000012 in ?? ()
  #19 0x00000003 in ?? ()
  #20 0x00000000 in ?? ()
  #21 0xc073a4de in Debugger (msg=0xc07b390c "panic") at machine/cpufunc.h:56
  #22 0xc05ddc85 in __panic (file=0xc07ba1fb "/usr/src/sys/kern/vfs_subr.c", line=0x2f3, 
      fmt=0xc07ba264 "cleaned vnode isn't") at /usr/src/sys/kern/kern_shutdown.c:532
  #23 0xc06259b0 in getnewvnode (tag=0xc07bdc45 "ufs", mp=0xc399d000, vops=0x0, vpp=0x0)
      at /usr/src/sys/kern/vfs_subr.c:785
  #24 0xc06f7cb0 in ffs_vget (mp=0xc399d000, ino=0x3944d1, flags=0x2, vpp=0xd7c05a84)
      at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1252
  #25 0xc06fe9da in ufs_lookup (ap=0xd7c05b40) at /usr/src/sys/ufs/ufs/ufs_lookup.c:599
  #26 0xc0704ae7 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2819
  #27 0xc061deb1 in vfs_cache_lookup (ap=0x0) at vnode_if.h:82
  #28 0xc0704ae7 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2819
  #29 0xc0622377 in lookup (ndp=0xd7c05c30) at vnode_if.h:52
  (kgdb) f 30
  #30 0xc0621df8 in namei (ndp=0xd7c05c30) at /usr/src/sys/kern/vfs_lookup.c:179
  179                     error = lookup(ndp);
  (kgdb) p *ndp
  Bus error (core dumped)

I'd be happy to try other versions if people can give me some
reason to expect that they might do better.  The data in question is
accessible: I can get at it with ddb, and it used to be possible with
gdb.  I suspect that the problem might be in a library, since older
gdbs from other machines have the same problem, but they don't on the
older machines.

Greg
--
Note: I discard all HTML mail unseen.
Finger grog_at_FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.