Re: A more accurate System.map, including modules

Richard Gooch (rgooch@atnf.CSIRO.AU)
Mon, 22 Sep 1997 22:49:13 +1000


Keith Owens writes:
> On 22 Sep 1997 04:41:15 GMT,
> hpa@transmeta.com (H. Peter Anvin) wrote:
> >Suggestion: make insmod log the location of each module in the system
> >log, or have the kernel output that information ("kernel: loaded
> >module foo at 0xe0801130). Then one could use that information from
> >the system log to decode the oops, without involving /proc/ksyms.
>
> Possible as long as you logged which file the module came from, what
> name is was loaded under and when modules were removed. Something like
>
> loaded module /lib/modules/2.1.55/net/dummy.o as dummy3 at 0xc1234567
> ....
> deleted module dummy2

Bugger. I just saw this after I sent in my previous message where I
suggested you support the simpler format of:
"kernel: loaded module foo at <hex_address>".

You have a point there: logging the filename of the module would be
quite nice. Unfortunately, while insmod can provide the information,
any logging it generates goes to /var/log/messages, not to
/var/log/kernel. Unless someone knows of a way for a userland process
to send message to the kernel log file (LOG_KERN doesn't seem to
work). The syslog(3) interface doesn't seem to support this.
Still, I don't see much option other than to modify insmod if you
decide you have to have access to filenames: the kernel isn't going to
know.

> And hope that you do not lose any log messages. Either way you still
> have to go to the raw module .o file to get the full symbol map, it is
> the only place that lists static procs.
>
> Using the full /proc/ksyms gave me the extra benefit of checking ksyms
> against the supplied map and modules to ensure they matched. You would
> loose this ability with simple log entries. I think the best option is
> regular and/or exception capture of /proc/ksyms to an external file.

Yes, although I would also like to see a mode where you use and old
logfile and ignore /proc/ksyms entirely, so you can do offline
debugging.

Regards,

Richard....