Hi Dave, Am Mittwoch, den 22.04.2009, 09:18 -0400 schrieb Dave Anderson: > ----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> 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 every other directory under "./"? Currently "mod -S" searches in all directories. > And then my proposed enhancement would search for the associated > ko.debug files in: > > ./usr/lib/debug/lib/modules/... ... and every other directory under "./"? > 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. Yes! That would be a good solution. > 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. No. I thought that you where suggesting to search only in <-S dir>/lib/modules.. and <-S dir>/usr/lib/debug/.. As I said before, "mod -S <dir>" currently searches in all subdirectories of <dir>. Michael -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility