10:17 a.m.
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(a)redhat.com> wrote:
----- "Michael Holzheu" <holzheu(a)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