Re: having System.map reflect the running kernel

Marty Leisner (leisner@sdsp.mc.xerox.com)
Wed, 30 Aug 1995 08:22:18 PDT

> > Some applications (lsof? maybe others?) need a system map
> > file which is an accurate reflection of the running kernel.
> >
> > [omitted]
>
> Definitely. Here's what I would consider a more elegant solution,
> although it requires more work:
>
>
> This suggests the following:
>
> 1. lilo supplies to the kernel the path of the kernel that was
> actually booted.
>
> 1a. The kernel remembers this string, turns it into an inode reference
> at boot time, and causes the image to appear as /proc/image.
>
> 2. system.map is appended to vmlinuz (and not loaded by lilo) so it
> always goes with the right image.
>
> 3. programs needing system.map get it from /proc/image.
>

I use loadlin (I'm now booting one machine via NT boot sequence into
Windows95 boot sequence into dos into loadlin...maybe I need to change
what I'm doing...)

But I've been happy with loadlin...

When we make a compressed kernel, why don't we keep the symbols in the image
(I think its stripped now).

Then, after booting and fsck'ing root, the kernel needs to know where it came
from...then some script after bootup could make a copy of a running kernel
into a constant, known file (uncompressing and stripping off the boot
sequence in compressed images...).

This strategy can also work with lilo/vmlinuz kernels (i.e. images of
kernels can be copied to a know location or linked. So all tools which want to
read the kernel symbols will know where to go (instead of specifying an
image name if the default isn't used).

I'd rather forget about the system.map stuff and just get kernel symbols
in a normal way (in the image).../proc/image doesn't need to have the symbol
table...
marty
leisner@sdsp.mc.xerox.com
Member of the League for Programming Freedom