[Crash-utility] Re: Symbol info from System.map vs. DLKM-debuginfo

[Dave Anderson]

----- "Alex Sidorenko" <asid at 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