[Crash-utility] After feedback on crash patch

Dave Anderson anderson at redhat.com
Wed Apr 25 21:00:50 UTC 2012



----- 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-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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod.patch
Type: text/x-patch
Size: 1201 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120425/f4f6f9b6/attachment.bin>


More information about the Crash-utility mailing list