[Crash-utility] After feedback on crash patch

[Dave Anderson]

----- Original Message -----
> Hi,
> 
> I'd like to get crash changed to add a new option to the mod command
> in crash. If you've got a dump server and you've got debuginfo RPMs
> extracted for pretty much every RHEL/SLES release you can create a
> symlink in the same directory as the vmcore pointing to the correct
> namelist, for example:
> 
> vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux
> 
> I'd like to see the mod command automatically work out where the
> debug modules will be based upon the result of realpath(3) on the
> namelist then removing everything after /usr/lib/debug. I know that
> there's the "--mod directory" option but you've got to remember to
> run it all the time and if you've extracted the kernel debuginfo
> crash can easily work out where they are if you use either a full or
> relative path or symlink to the namelist. I don't know if anyone
> would prefer to see it implemented in a different way but rather
> than risk breaking something I didn't understand I added a new -t
> option instead (-t because it's similar to -S and t is the next
> available option after the letter s).
> 
> I've run it on a few dumps and it seems to be working correctly. All
> of the code changes are in kernel.c, help.c needed some changes just
> to add the help text. Any feedback would be appreciated.
> 
> Thanks
> Shane

It's a reasonable idea, but it seems that the eventual "tree" that is 
selected should be more restrictive.  Here's what I mean...

It works nicely using the setup that you describe:

 vmlinux -> /debuginfo/x86_64/rhel5/2.6.18-164/usr/lib/debug/lib/modules/2.6.18-164.el5/vmlinux

So on my workstation, I set up a sample tree like so, where "mod -t" 
with CRASHDEBUG(3) shows this:

 REL namelist: vmlinux
 REL realpath: /tmp/mydebuginfos/usr/lib/debug/lib/modules/2.6.18-128.el5/vmlinux
 REL short path: /tmp/mydebuginfos/usr/lib/debug/

and it found the <module>.ko.debug files OK.

But on an internal server, we have a directory structure like this:

 /cores/debuginfo/x86_64/usr/lib/debug/lib/modules

And in that "modules" directory, there are dozens of "2.6.x" kernel version 
debuginfo trees.  So taking one example using a symbolically linked vmlinux
file, "mod -t" shows this:
  
 REL namelist: vmlinux
 REL realpath: /cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64/vmlinux
 REL short path: /cores/debuginfo/x86_64/usr/lib/debug/

But unfortunately it just grabs whichever "<module>.ko.debug" it finds
first -- which invariably comes from the wrong kernel version tree, because
there are dozens of each <module>.ko.debug file to select from.

If it used "/cores/debuginfo/x86_64/usr/lib/debug/lib/modules/2.6.32-220.2.1.el6.x86_64",
as the "short path", then it would find the correct (only) <module>.ko.debug files.
  
So would there be a problem in having the "short path" include the parent 
directory that contains the vmlinux file?

We also compress the vmlinux files for space-saving.  You might
also test what happens when the local symbolic link is to a
vmlinux.gz file, because pc->namelist will point to the
uncompressed tmpname-generated file instead of back into the 
original tree.

Thanks,
  Dave