[Crash-utility] Re: Symbol info from System.map vs. DLKM-debuginfo
----- "Alex Sidorenko" <asid(a)hp.com> wrote:
Hi Dave,
while working on an NFS problem (Ubuntu/Hardy) I needed to get definitions
of 'struct svc_cacherep'. I have compiled nfsd.ko with debugging for an older
kernel.
Current kernel: 2.6.24-24-generic
nfsd.ko: 2.6.24-21-generic
The definition of 'struct svc_cacherep' is the same. To avoid rebuilding
nfsd.ko I decided to specify /boot/System.map-2.6.24-generic explicitly.
Before loading 'nfsd.ko' the address of 'lru_cache' variable is correct,
but
after loading old nfsd.ko it changes:
crash32> sym lru_head
f908b988 (b) lru_head
crash32> mod -s nfsd
/usr/lib/debug/lib/modules/2.6.24-21-generic/nfsd.ko
MODULE NAME SIZE OBJECT FILE
f908a280 nfsd 228976
/usr/lib/debug/lib/modules/2.6.24-21-generic/nfsd.ko
crash32> sym lru_head
f908b984 (b) lru_head
Is this expected? It would be nice to be able to give precedence to symbols as
defined in System.map (maybe a startup option or internal set option).
I'm not sure I completely understand, but there shouldn't be any reference at
all in your System.map file to any kernel module symbols, i.e, it should only
contain symbols from the vmlinux file. So the System.map file should have no
bearing upon the change in the nfsd module's "lru_head" address.
What has happened is that the original "lru_head" address of f908b988 came
from the address that was exported to the kernel from the nfsd.ko module
when the module was insmod'd. (i.e., having nothing to do with the crash utility)
Then the crash utility was then brought up, and it found that f908b988 address
was exported to the kernel via the "good" nfsd.ko module structure data. The
first "sym lru_head" command shows that address.
However, then you loaded (via an internal "add-symbol-file" gdb operation) the
older nfsd.ko module's information into the crash utility -- and it overwrote the
original symbol value data with that from the (non-matching) nfsd.ko that contains
the incorrect f908b984 address. So the crash utility is just doing what you told
it to do. There's no support for loading a module that doesn't match reality,
and
continuing to use the old (correct) symbol addresses.
Dave