lkcd
[Top] [All Lists]

Re: Module support

To: lkcd@xxxxxxxxxxx
Subject: Re: Module support
From: "T.Ohno" <ohno@xxxxxxxxxxxxxxx>
Date: Wed, 18 Jul 2001 18:11:59 +0900
Cc: j-kondo@xxxxxxxxxxxxxxx
References: <F13508319A1CD41187DE00508BACED6A020673AD@xxxxxxxxxxxxxxxxx> <20010717113618I.j-kondo@xxxxxxxxxxxxxxx>
Sender: owner-lkcd@xxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; JAPressMailingNov00) Gecko/20001108 Netscape6/6.0
Dear all

KONDO Jyunji wrote:

Hi, hiro.


Has anyone tried to make lcrash support modules. If no one has,
I guess I have to reverse-engineer the query_modules system call.
Am I correct?


We are trying to do that by extending lcrash and using ksymoops.


Since most of our proprietary kernel code (device drivers) is
in module, LKCD is not very useful with module support...


I agree...

At the moment, we are fixing our ideas and we'll be post it to this
group soon.
Please wait a moment.

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.

 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.

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.

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


<Prev in Thread] Current Thread [Next in Thread>