Re: Loading debuginfo symbols

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> Hi,
> 
> I would like to be able to load symbols from a specific debuginfo directory using
> 'mod -S <dir>'.  This works if you unpack the corresponding kernel rpm too but I'd
> like to be able to save on the disk space by just using the debuginfo rpm.  This
> currently doesn't work because crash doesn't explicitly search for modules ending
> in .ko.debug.  The simple patch below adds this support.  Is this a sensible change
> to make or is there a better way to do this?
> 
> Lachlan

It's not only sensible -- I've already got a similar patch queued for 6.0.1!

Here's the changelog entry:

         - If the "--mod <directory-tree>" command line option, or the
           setting of the CRASH_MODULE_PATH environment variable, or the
           "mod -S <directory-tree>" point to a tree that contains only the
           separate debuginfo "&lt;module>.ko.debug" files, then those
           debuginfo files will be used as the internal "add-symbol-file"
           arguments to the embedded gdb module.  Without the patch, it was
           only acceptable to point to a directory tree that contained the
           base "<module>.ko" files, and the separate debuginfo files
           were found automatically based upon the directory path to the
           base module file.  This will allow an alternate module-debuginfo
           directory tree to be set up like so:

             # cd <directory>
             # rpm2cpio kernel-debuginfo-<release>.rpm | cpio -idv

           Having done that, the <directory> may be used with the "--mod",
           command line argument, or as the CRASH_MODULE_PATH environment
           variable, or as the "mod -S <directory> argument.
           (anderson@xxxxxxxxxx)

It works OK for x86, x86_64 and ppc64 anyway -- although it seems to me that
in the distant past (perhaps with an earlier version of gdb?), that it did 
*not* work.  But if it does, it certainly makes housekeeping easier.

Be also aware that x86 and x86_64 line number capability is also spotty with
crash-6.0.0 due to changes in the way gdb-7.3.1 handles them.  But I've got
6.0.1 fixes queued for those issues as well.

Dave

> 
> diff -up crash-5.1.9/kernel.c.orig crash-5.1.9/kernel.c
> --- crash-5.1.9/kernel.c.orig	2011-11-08 14:15:51.467399576 +1100
> +++ crash-5.1.9/kernel.c	2011-11-09 14:26:23.264253341 +1100
> @@ -3588,7 +3588,10 @@ module_objfile_search(char *modref, char
>  			{
>  			case KMOD_V2:
>  				sprintf(file, "%s.ko", modref);
> -				retbuf = search_directory_tree(tree, file, 1);
> +				if (!(retbuf = search_directory_tree(tree, file, 1))) {
> +					sprintf(file, "%s.ko.debug", modref);
> +					retbuf = search_directory_tree(tree, file, 1);
> +				}
>  			}
>  		}
>  		return retbuf;
> @@ -3605,7 +3608,10 @@ module_objfile_search(char *modref, char
>  			{
>  			case KMOD_V2:
>  				sprintf(file, "%s.ko", modref);
> -				retbuf = search_directory_tree(dir, file, 0);
> +				if (!(retbuf = search_directory_tree(dir, file, 0))) {
> +					sprintf(file, "%s.ko.debug", modref);
> +					retbuf = search_directory_tree(dir, file, 0);
> +				}
>  			}
>  		}
>  	}
> 
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
> 

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility


[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux