> -----Original Message-----
> From: KONDO Jyunji [mailto:j-kondo@xxxxxxxxxxxxxxx]
> Sent: Monday, July 16, 2001 19:36
> To: lkcd@xxxxxxxxxxx
> Subject: Re: Module support
>
>
>
> 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...
^^^^
Of course, I meant _without_ ;-)
> 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'm happy to know that it sounds like there are some activities
going on about modules support. I'd like to see a fairly automated
mechanism like GDB's shared library auto-loading. I would expect
a few new commands like "set module-prefix" and "lsmod." The
"set module-prefix" command sets the module file loading path prefix
which is necessary for a cross environment where lcrash runs on a
different machine from the target; "lsmod" should be almost identical
to Linux' lsmod with additional module loading address display.
BTW, I have always been thinking that the "System.map" argument is
redundant. It could be replaced with a shell command line like:
`nm vmlinux|awk --posix '{if ($1 ~ /c[[:xdigit:]]{7}$) print}'|sort|uniq`
(Some nm's seem to use 64 bit addresses. So, do not put an assumption
of an 8-digit address field)
This way, lcrash would only need the module binary files (with debug
information for the better, but not mandatory).
hiro
|