Re: A more accurate System.map, including modules
Richard Gooch (rgooch@atnf.CSIRO.AU)
Mon, 22 Sep 1997 22:29:15 +1000
Keith Owens writes:
> On Mon, 22 Sep 1997 09:01:56 +1000,
> Richard Gooch <rgooch@atnf.CSIRO.AU> wrote:
> >Keith Owens writes:
> >> ftp://ftp.ocs.com.au/make_System_map.pl.gz (3.5K) builds a more
> >> accurate map from your existing System.map, the information from
> >> /proc/ksyms and your modules directories.
> >
> >This is a good step forward, but it requires that after you get an
> >oops enough of the system is still left running that you can run
> >ksymoops. I've had a few cases where syslogd is still logging, but I
> >can't run commands. Going back later (after a reboot) and running
> >make_System_map.pl doesn't work because the location of modules has
> >changed. This is especially the case for people running kerneld.
> >What about modifying klogd to do the things ksymoops does?
>
> Same problem, make_System_map has to run commands and open files, if
> only to read /proc/ksyms and get the nm data for the modules. If you
> cannot issue cat or nm commands yourself, then klogd is going to have
> the same problem.
>
> However all that is required to diagnose an oops after the machine has
> been rebooted is the data in /proc/ksyms at the time of the oops.
> Remember that make_System_map does not require the real /proc/ksyms, it
> can be a copy. ksyms is the only data that changes from run to run,
> System.map and modules are only changed by kernel recompiles. So what
> you really need is a way of capturing the current ksyms to a file when
> an oops occurs.
>
> That could be a simple extension to klogd, when an oops is detected,
> copy /proc/ksyms to a file and run a specified program such as
> make_System_map. If my approach to extending the map is accepted, I'll
> add that option to klogd later.
As I understand it, what changes /proc/ksyms from run to run is the
location of symbols in modules that are loaded (there's nothing else,
correct?). In that case, I quite like hpa's suggestion of logging the
base address of each module as it is loaded. You can go back later
with System.map and run ksymoops over an oops that did not get saved
to disc, but was recorded with pen and paper. That would deal with the
worst-case scenario.
And klogd could keep track of loaded modules with that scheme as well
(you would also want a log message for when a module is unloaded).
Ideally, you would want klogd/ksymoops to use System.map, but if that
is not available /proc/ksyms should be used as a fallback.
How about modifying your make_System_map programme so that it can use
the module loading/unloading messages in a logfile *instead of*
/proc/ksyms? That would then allow you to build a complete System.map
from the kernel-build System.map + module *.o files + old logfile,
useful for offline debugging.
Of course, there's no current logging of module loading and unloading
in the kernel, but how about supporting the following format suggested
by hpa:
"kernel: loaded module foo at <hex_address>"
coping with the leading "<date> <hostname> " stuff that syslogd
prepends, if it's there?
And of course:
"kernel: unloaded module foo"
If you feel like doing this, I'll submit patches for 2.1.x and 2.0.x
to implement this.
Regards,
Richard....