Andreas Herrmann wrote:
>
> >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.
This is a fundamental problem in the kernel build mechanisms. It
would be nice to avoid this scenario, but there's no clear way of
merging any of the files together.
I don't view this as an lcrash problem, but a kernel build problem.
> Second: Currently there is no automatism to load symbol tables and
> namelists.
I'm not sure what you mean here ... you don't mean what 'vmdump save'
does, right? Are you talking about copying the files to /boot, or
saving them to /var/log/vmdump, or something else?
> 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.
Most people won't put up with building their entire kernel -gstabs.
If that were the case, we would have done that a long time ago. I
think it would be _GREAT_ to have that, but most people gag on the
idea of putting all symbols into the kernel, as it creates huge
kernels.
> 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.
We already tie the symbol.map file and the kernel together via a
kernel_magic field. If that isn't working correctly, it should be
fixed.
Alternatively, we can tie all three together via the same mechanism.
> >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
Good notes ...
--Matt
|