Thanks for the information, Andreas.
I am actually wondering if I need to implement the front-end portion
by myself with a different approach because our Linux application is
purely embedded: The target system does not have a swap device and
instead a dedicated 1MB flash memory is assigned for kernel crash
dump saving. Well, the system has a total of 64MB RAM partially used
for RAMfs. So, unless I can invent a super compression algorithm of
some 64 to 1, I need to make lkcd save only selected memory segments
of "true interest" because I cannot have the luxury of saving the
whole memory contents.
So, we are developing a prioritized kernel memory coloring scheme
for crash dump saving. For example, the current process' task_struct
and stack are the most important followed by those of "user processes."
The kernel's static storage (data and bss) is also interesting but
it's probably difficult to save the entire kernel heap.
Another area for reducing the dump size may be improvement of data
compression. I am not a data compression algorithm expert, but I
can expect, even with the current simple RL algorithm, some saving
by zero-clearing each process stack in sys_fork (if not yet done
so).
So, as to the module list, I may wish to save a "module directory"
segment with a flags bit set in the page header instead of having
lcrash search for it in the general page dump. If each module's
name, file path, and text, data, bss base addresses are saved,
it's not too difficult to relocate the symbols in the module file
lcrash.
Any suggestions are welcomed.
hiro
> -----Original Message-----
> From: Andreas Herrmann [mailto:AHERRMAN@xxxxxxxxxx]
> Sent: Wednesday, July 18, 2001 06:57
> To: lkcd@xxxxxxxxxxx
> Subject: Re: Module support
> The new command "module" helps to investigate module structures in
> the dump. The starting point is the variable module_list of the
> kernel. It is the anchor of a chained list of structures of kind
> "struct module". Some information, received from these structs,
> can be displayed by using the "module" command.
> The second new command is "symtab". It is used for handling of
> multiple symbol tables. You can add, remove and show information of
> symbol tables. The command can automatically detect the segment
> offsets when symbol tables for modules are loaded. It uses a mechanism
> like ksymoops to detect the offsets.
> By the way, lcrash creates an additional symbol table "ksymtab" during
> startup. It contains all exported kernel symbols. From this table the
> segment offsets of modules are extracted. But the exploitation of this
> symbol table can and should be improved to use it as a default
> table when searching for symbols during "dis", "trace" etc.
>
> The advantages in having multiple symbol tables are:
> - findsym, dis, trace, strace, whatis commands can find symbol
> names of functions located in modules (iff symbol tables were
> previously added)
> - symbol tables can be removed and again added without restart of
> lcrash - I find it quite comfortable, if wrong table was loaded or
> while playing around with a live system and different module
> versions
|