[Crash-utility] mod -S and debuginfo kernel rpm

[Dave Anderson]

----- "Michael Holzheu" <holzheu at 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