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

[Michael Holzheu]

Hi Dave,

Am Mittwoch, den 22.04.2009, 09:18 -0400 schrieb 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 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