bin/46068: GDB can no longer display kernel addresses symbolically on i386

[gson%gson.org@localhost (Andreas Gustafsson)]

>Number:         46068
>Category:       bin
>Synopsis:       GDB can no longer display kernel addresses symbolically on i386
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 21 20:20:00 +0000 2012
>Originator:     Andreas Gustafsson
>Release:        NetBSD-current >= 2011.10.10.14.07.16
>Organization:
>Environment:
System: NetBSD
Architecture: i386
Machine: i386
>Description:

GDB seems to have lost the ability to display function addresses
symbolically when debugging a kernel on i386.

Specifically, it fails when debugging an actual kernel file, such as
/netbsd.  It works when debugging a "fake" kernel image saved by
savecore, such as /var/crash/netbsd.0.

For example, if you follow the instructions in PR 45677 that tell you
to download

  http://www.gson.org/netbsd/bugs/45677/wd0.img

boot it with

  qemu -snapshot -nographic -hda wd0.img

and type

   cd /var/crash
   gunzip netbsd*
   gdb netbsd.0
   target kvm netbsd.0.core
   where

gdb will complain about a lack of debug symbols:

  Reading symbols from /var/crash/netbsd.0...(no debugging symbols 
found)...done.

but you will still get a fairly readable stack trace:

  #0  0xc05d62e3 in cpu_reboot ()
  #1  0xc07d16aa in vpanic ()
  #2  0xc07d174f in panic ()
  #3  0xc07cd9cc in pool_get ()
  #4  0xc07cf4a9 in pool_cache_put_slow ()
  #5  0xc07cfec0 in pool_cache_put_paddr ()
  #6  0xc07c8391 in kmem_intr_free ()
  #7  0xc086ffed in ufs_readdir ()
  #8  0xc09123d8 in VOP_READDIR ()
  #9  0xc08e1a35 in getcwd_common ()
  #10 0xc08e1d4b in sys___getcwd ()
  #11 0xc07f5d8d in syscall ()
  #12 0xc01005d6 in Xsyscall ()

No function arguments are displayed, but at least we have the function
names.  However, if instead of /var/crash/netbsd.0 you point gdb at
the actual kernel, /netbsd:

  gdb /netbsd
  target kvm netbsd.0.core

GDB no longer complains about a lack of debug symbols:

  Reading symbols from /netbsd...done.

But instead of being improved, the stack trace is now completely
unreadable:

  #0  0xc05d62e3 in ?? ()
  #1  0xc07d16aa in ?? ()
  #2  0xc07d174f in ?? ()
  #3  0xc07cd9cc in ?? ()
  #4  0xc07cf4a9 in ?? ()
  #5  0xc07cfec0 in ?? ()
  #6  0xc07c8391 in ?? ()
  #7  0xc086ffed in ?? ()
  #8  0xc09123d8 in ?? ()
  #9  0xc08e1a35 in ?? ()
  #10 0xc08e1d4b in ?? ()
  #11 0xc07f5d8d in ?? ()
  #12 0xc01005d6 in ?? ()

>How-To-Repeat:

Here is a minimal test case that doesn't require downloading a large
disk image like the above example.  Simply type, on any -current/i386 system,

  gdb /netbsd
  print cpu_reboot

You will see something like this:

  $1 = {<text variable, no debug info>} 0xc05a2b56

On an older system, you will see something like this:

  $1 = {<text variable, no debug info>} 0xc05a2b56 <cpu_reboot>

Note that the <cpu_reboot> at the end of the line is missing in -current.

Using automated binary search based on the presence of the <cpu_reboot>
in the above test case, I have narrowed down the regression to between
CVS dates 2011.10.08.19.16.08 and 2011.10.10.14.07.16.  A number of gdb
changes were committed in this interval.

The problem does not affect -current/amd64 nor -current/sparc, nor
the debugging of userland programs.

>Fix: