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

[Dave Anderson]

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