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