[Crash-utility] After feedback on crash patch

[Seymour, Shane M]

Hi Dave,

I'll give that a whirl today and let you know.

Thanks
Shane

-----Original Message-----
From: Dave Anderson [mailto:anderson at redhat.com] 
Sent: Thursday, April 26, 2012 7:01 AM
To: Discussion list for crash utility usage, maintenance and development
Cc: Seymour, Shane M
Subject: Re: [Crash-utility] After feedback on crash patch



----- Original Message -----
> 
> 
> ----- 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-16
> 4.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.x
> 86_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

Shane,

How does the attached patch work for you?  It should just work automatically without any additional arguments, because when all else fails, it will search
for modules starting from the directory containing the vmlinux or vmlinux.gz file.   

Dave