[Crash-utility] mod -S and debuginfo kernel rpm

[Michael Holzheu]

Am Dienstag, den 21.04.2009, 11:17 -0400 schrieb Dave Anderson:
> Hi Michael,
> 
> I knew this sounded familiar, but there is an option for adding
> an alternative search directory starting point to "mod -S":
> 
>   crash> help mod
> 
>   NAME
>     mod - module information and loading of symbols and debugging data
> 
>   SYNOPSIS
>     mod [ -s module [objfile] | -d module | -S [directory] | -D | -r | -o ]
> 
>   ... [ snip ] ...
> 
>          -S [directory]  Load symbolic and debugging data from the object file
>                          for all loaded modules.  For each module, a search
>                          will be made for an object file consisting of the
>                          module name with a .o or.ko suffix, starting at the
>                          /lib/modules/<release> directory of the host system.
>                          If a directory argument is appended, then the search
>                          will be restricted to that directory.
>   ... [ snip ] ...
> 
> However -- although this option would allow you to specify your local
> directory tree containing the stripped module files, I don't think that
> the gdb algorithm will be able to find the associated .ko.debug files
> (unless you moved them into the same directory).
> 
> As I recall, the [directory] option above was put in place back in the day
> when the modules were not split into .ko and .ko.debug files.  I may be
> wrong, but I don't think so.  Give it a shot anyway.

That's what I used. In particular I did the following:

# mkdir mydump
# cd mydump
# rpm2cpio kernel-2.6.18-128.el5.s390x.rpm | cpio -idv
# rpm2cpio kernel-debuginfo-2.6.18-128.el5.s390x.rpm | cpio -idv

Then I called:

# mod -S lib/modules/2.6.18-128.el5/

That only loads the stripped modules. It does not search locally.

Michael