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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
