----- "Alex Sidorenko" <[email protected]> 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 -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
