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

[Dave Anderson]

Hi Michael,

I knew this sounded familiar, but there is an option for adding
an alternative search directory starting point to "mod -S":

  crash> help mod

  NAME
    mod - module information and loading of symbols and debugging data

  SYNOPSIS
    mod [ -s module [objfile] | -d module | -S [directory] | -D | -r | -o ]

  ... [ snip ] ...

         -S [directory]  Load symbolic and debugging data from the object file
                         for all loaded modules.  For each module, a search
                         will be made for an object file consisting of the
                         module name with a .o or.ko suffix, starting at the
                         /lib/modules/<release> directory of the host system.
                         If a directory argument is appended, then the search
                         will be restricted to that directory.
  ... [ snip ] ...

However -- although this option would allow you to specify your local
directory tree containing the stripped module files, I don't think that
the gdb algorithm will be able to find the associated .ko.debug files
(unless you moved them into the same directory).

As I recall, the [directory] option above was put in place back in the day
when the modules were not split into .ko and .ko.debug files.  I may be
wrong, but I don't think so.  Give it a shot anyway.

The gdb code is in gdb-6.1/gdb/symfile.c:find_separate_debug_file().
Perhaps a callback function could be put in place there if a [directory]
argument was used.

Dave




----- "Dave Anderson" <anderson at redhat.com> wrote:

> ----- "Michael Holzheu" <holzheu at linux.vnet.ibm.com> wrote:
> 
> > > That is by intention.  The argument to the "mod" command should be
> > > the stripped "<module_name>.ko" file.  When loading that file, the
> > > embedded link to the "<module_name>.ko.debug" file found in the
> > > stripped "<module_name>.ko" file should be recognized and handled
> > > internally by the embedded gdb module.
> >
> > From where gets gdb this link? Is it somewhere stored in the ELF
> module
> > file?
> 
> There is the .gnu_debuglink section in the module that contains just
> the name
> of the associated .ko.debug file along with a CRC value to ensure it's
> the correct
> one after it finds it:
> 
>   $ objump -s /lib/modules/2.6.18-128.el5/kernel/fs/ext3/ext3.ko
> 
>   ... [ snip ] ...
> 
>   Contents of section .gnu_debuglink:
>    0000 65787433 2e6b6f2e 64656275 67000000  ext3.ko.debug...
>    0010 5392d21a
>   $
> 
> And then gdb takes it from there.  The embedded version of gdb
> (gdb-6.1)
> inside crash looks for the associated ext3.ko.debug file in 3
> directories,
> based upon first creating a fully-qualified path to the directory
> containing the stripped module files:
> 
> (1) in the same directory containing the stripped module
> (2) in the .debug subdirectory of the directory containing the
> stripped module
> (3) in /usr/lib/debug/<path-to-module-directory>
> 
> And so normally it finds the associated .ko.debug file in
> /usr/lib/debug/lib/modules/<release>/<path-to-module-directory>.
> 
> >
> > What I want to do is to unpack the kernel rpm and kernel debuginfo
> rpm
> > to my local directory and then load the modules with "mod -S"
> > In my local directory I have lib/modules/2.6.18-128.el5/ with the
> kernel
> > modules and usr/lib/debug/lib/modules/2.6.18-128.el5/ with the
> .debug files.
> >
> > When I use "mod -S lib/modules/2.6.18-128.el5" the debug information
> > seems not to be loaded.
> 
> With "mod -S", it will use the fully qualified pathname to the
> stripped module
> as the starting point, i.e.,
> /lib/modules/<release>/<path-to-module-directory>.
> It will look in that directory, in the .debug subdirectory in that
> directory,
> and finally in
> /usr/lib/debug/lib/modules/<release>/<path-to-module-directory>.
> 
> In your case, crash has no idea where you put the modules, so you
> would have
> to manually specify where each of the stripped modules are located
> with
> "mod -s <module> <your/directory/path/stripped-module-name>, and then
> put the
> associated .ko.debug in the same directory as each stripped module.
> 
> Any other behaviour such as what you're expecting would require a
> patch
> to kernel.c:module_objfile_search(), at the very bottom of the
> function
> just prior to it returning with a retbuf of NULL (which is what's
> happening
> to you now).  But even there, it would find the stripped module, but
> the
> gdb mechanism for finding the associated .ko.debug file would fail
> unless
> you manually moved the .ko.debug files into the same directory where
> their
> associated stripped module is located.
> 
> Dave