Re: on debugging loadable modules...

Keith Owens (kaos@audio.apana.org.au)
Thu, 14 Mar 1996 12:57:53 +1100 (EST)


On Tue, 12 Mar 1996, David S. Miller wrote:
> I was thinking about the problems we are seeing with debugging
> loadable modules since their text/data symbols are determined at run
> time. Maybe we should try to implement something like this:
>
> * Each module when it loads does a low-priority printk
> perhaps KERN_MODULE? Syslog/klog is told to place messages
> at this level to /var/adm/module.log or whatever. Basically
> the printk looks like this:
>
> smc_ultra_module: Loading image at base vaddr 0xdeadbeef
>
> Maybe /proc/modules or something like that can hold this
> information around while the machine is running also.

This should be done by insmod/kerneld. Same processing for all modules,
best done by the loader instead of by each code module.

> * Each module, at compile time has 'nm' run on it after it is
> built producing a zero-relative foo_module.map

Fine.

> * Ksymoops is modified to understand this scheme and then trace
> properly through kernel modules using either the proc filesystem
> entries (if the machine didn't die from the oops) or extracting
> the lines from /var/adm/module.log when the machine comes
> back up _and_ the module.map file.

Problem with running ksymoops after the event is that the current system
might not match the modules running when the oops occurred. ksymoops
would have to read all the way through a log to work out which modules
were loaded at the oops point, messy. Suggest that the loaded module data
be printed as part of the oops, one off data instead of log scanning and
interpretation.