----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com&gt; wrote: > > So for example, if the target "mod -S [directory]" was specified to be ".", > > there would be "./lib/modules" and "./usr/lib/debug/lib/modules" subdirectory > > trees. > > > > And then "mod -S [directory]" would just work. > > Doesn't this change the current behavior? Currently the search is > restricted to the directory specified with mod -S. You would change that > and search only <-S dir>/lib/modules.. and <-S dir>/usr/lib/debug/..> ? It doesn't change the current behavior, but rather enhances it to also make the search for the associated ko.debug files in the same subdirectory tree. The current behavior of "mod -S [directory]" is to restrict the search for the stripped .ko files to the specified directory. But then if the "found" stripped .ko file is linked to a .ko.debug file, then the standard gdb rules are applied for finding the associated ko.debug files, i.e., in that same directory where the stripped .ko file exists, in a .debug subdirectory there, or finally, in the global /usr/lib/debug/lib/modules/<release>/... tree. Sorry if I keep repeating myself... > > So maybe a new prefix option (-P ?) might be better: > > (4) Search stripped modules in <-P dir>/lib/modules/ and debug modules > in <-P dir>/usr/lib/debug/lib/modules/ We already have the "Search stripped modules in <-P dir>/lib/modules" capability in place. That's "mod -S [dir]" as it works now. The question is whether it makes sense to restrict the location of the associated debuginfo tree to the same root directory as the "mod -S [dir]" directory. So when you stated: > 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. My suggestion would allow you to do this: # 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 # crash ... crash> mod -S . and then the stripped modules would be searched for in: ./lib/modules/...

And then my proposed enhancement would search for the associated ko.debug files in: ./usr/lib/debug/lib/modules/...

So no changes to the current "mod" command options would be required. And taking Guy's request, where a central machine may be dedicated to storing dumpfiles, they could to the "double-rpm2cpio" in a static location, with one "double-tree" per kernel release. With that in place, the would always have the double-tree in place, and then could run: crash> mod -S <path-to>/<release-double-tree> Seems pretty straight forward to me. And as always, I'm just trying to keep things as simple as possible.

The question is whether you are suggesting that it would be common to have the /lib/modules tree rooted in one location, and the /usr/lib/debug/lib/modules tree rooted elsewhere.