Re: [Crash-utility] mod -S and debuginfo kernel rpm
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> 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.
Is that what you're saying?
Dave