Looking at the vmlinux files with dwarfdump and gdb 6.3 alone, I can see now that in the target 2.6.16 xen kernel (built with gcc 4.0.0, if that matters), what is happening is that for static kernel data that is declared without being initialized, its data type information is being completely left out of the debug info section. So, taking kernel/pid.c as an example, symbols such as "pid_hash", "pidhash_shift" and "last_pid" are declared uninitialized. Looking at the 2.6.16 xen kernel built with gcc 4.0.0: # gdb vmlinux GNU gdb Red Hat Linux (6.3.0.0-1.63rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". (gdb) whatis last_pid type = <data variable, no debug info> (gdb) whatis pid_hash type = <data variable, no debug info> (gdb) whatis pidhash_shift type = <data variable, no debug info> (gdb) Then looking at a non-xen 2.6.16-era kernel built with gcc 4.1.0: # gdb /usr/dumps/kdump/vmlinux GNU gdb Red Hat Linux (6.3.0.0-1.63rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". (gdb) whatis last_pid type = int (gdb) whatis pid_hash type = struct hlist_head *[4] (gdb) whatis pidhash_shift type = int (gdb) I don't believe the "xen" angle makes a difference. I only have 2.6.17-era xen kernels as a reference -- built with gcc 4.1.1 -- and they do not exhibit this behavior. I presume that this affects files other than kernel/pid.c, but haven't checked any further. So it would be interesting to know whether an upgrade in compilers would make a difference. Regardless of that, I'll still come up with a fix and release for this, since there's really nothing I can do with kernels of this ilk except to work around their shortcomings. If the debug data's not there, it's not there... Thanks, Dave