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@xxxxxxxxxx> wrote: > ----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility