>I am a Jyunji's co-worker. Now I will post our idea.
>
>I think Andreas's ideas are effective at debugging
>a specific module.
>
>Our idea is different from his one and aims at the
>investigation for detecting a system crash reason.
>
>Currently we are planning following procedure.
>
> 1. Extract symbols for debugging modules from
> dump file by using a new lcrash option or a
> dedicated command.
Which symbols do you like to extract from the dump?
As far as I know, the Linux system stores only information
about exported kernel symbols (ksyms). Usually only some
symbols of kernel modules are exported. Hence, your method
will likely miss the majority of symbol information for modules.
>
> 2. Create a System.map file including the all
> symbols of loaded modules by passing the
> result of #1 to ksymoops command.
>
>Using this System.map, the symbols of all modules
>which was loaded in kernel when system crash occurred
>are referable.
>
I think this is wrong. As above mentioned, only some symbols of
loaded modules can be referred. And maybe the system has died
while calling a module function, for which the symbol was not
exported ...
>In Andreas's idea, the modules installed at system
>crash or module map files must be saved and the map files
>must be loaded each lcrash.
>
I think we have two problems in current lcrash version.
First: Map-files (System.map, symbol information for
modules), "namelists" (Kerntypes, object files containing type information
for
modules), and the dump must belong together. So, it is a little tricky
to collect all corresponding files in order to analyze a dump of a
customer.
Second: Currently there is no automatism to load symbol tables and
namelists.
To "disarm" the situation we should think about the following:
- Receive symbol table not from map file, but from non-stripped object
file.
So, one object file (compiled with -gstabs) can be used to load both
symbol and type information of a module. It means to let lcrash extract
symbol
information itself - like "nm" does. This way assumes, that compile
option -gstabs generates the same code as without the option.
Is this really the case for all supported lkcd-platforms?
- Don't generate a separate Kerntypes file but use vmlinux
(compiled with -gstabs) itself for symbol and type information of the
kernel.
In order to do so, the kernel build process must be patched to spy out
also
this vmlinux version of the kernel.
- Introduction of a configuration file. E.g., there could be stored the
information, which symbol table and namelist to load for which module.
>In our idea, as the System.map at the system crash is
>generated, module replacement causes no problem
>(of course after generating System.map)
>and the dump is analyzable at another machine.
>
>Any comment and suggestion are welcomed.
>
>
>Toshio Ohno
Andreas
--
Linux for eServer Development
Tel : +49-7031-16-4640
Notes mail : Andreas Herrmann/GERMANY/IBM@IBMDE
email : aherrman@xxxxxxxxxx
|