As part of my penance for using the wrong System.map file in the
readprofile data I sent out, I have prepared a patch to readprofile
that makes it check the version of the file against the kernel.
Much to my dismay, the extraversion code ('-pre6' for example) does
not appear to be anywhere in System.map. Or am I wrong? If not, why
not, and can this be fixed? After all, symbols can and do change
between -pre versions.
Dr. Tom Holroyd
"I am, as I said, inspired by the biological phenomena in which
chemical forces are used in repetitious fashion to produce all
kinds of weird effects (one of which is the author)."
-- Richard Feynman, _There's Plenty of Room at the Bottom_
On Mon, 2002-04-08 at 02:07, Tom Holroyd wrote:
> As part of my penance for using the wrong System.map file in the
> readprofile data I sent out, I have prepared a patch to readprofile
> that makes it check the version of the file against the kernel.
>
> Much to my dismay, the extraversion code ('-pre6' for example) does
> not appear to be anywhere in System.map. Or am I wrong? If not, why
> not, and can this be fixed? After all, symbols can and do change
> between -pre versions.
Eh, no kernel version is associated with System.map. It has no embedded
information, what-so-ever, aside from the symbols.
Do what everyone else does and name your System.map appropriately, i.e.
System.map-2.5.8-pre2 and then on boot symlink System.map to
System.map-`uname -r`. Most (all?) distributions do this for you
already.
You can also pass readprofile the -m flag to specify the map file to
use. A little script that does "readprofile -m System.map-`uname -r`"
would work fine.
Robert Love
On Mon, 8 Apr 2002 15:07:23 +0900 (JST),
Tom Holroyd <[email protected]> wrote:
>As part of my penance for using the wrong System.map file in the
>readprofile data I sent out, I have prepared a patch to readprofile
>that makes it check the version of the file against the kernel.
>
>Much to my dismay, the extraversion code ('-pre6' for example) does
>not appear to be anywhere in System.map. Or am I wrong? If not, why
>not, and can this be fixed? After all, symbols can and do change
>between -pre versions.
System.map only contains the numeric kernel version. After all, it is
difficult to convert 2.4.19-pre6 to Version_132115-pre6 when symbols
cannot contain '-'.
Don't reinvent the wheel, use ksymoops -s save.map. ksymoops has all
the verification code that I can think off, -s writes the merged map
including module information.
On Mon, 8 Apr 2002, Keith Owens wrote:
> System.map only contains the numeric kernel version. After all, it is
> difficult to convert 2.4.19-pre6 to Version_132115-pre6 when symbols
> cannot contain '-'.
Well, that has an obvious solution, but modifying the Version string
would likely break something. Adding another string would work. It
could even be done without making the kernel image bigger. In fact,
the Version_* symbol (and Extraversion_* symbol) could both be made
__initdata, couldn't they?
> Don't reinvent the wheel, use ksymoops -s save.map. ksymoops has all
> the verification code that I can think off, -s writes the merged map
> including module information.
Now there's a clever idea.
On Mon, 8 Apr 2002 15:29:47 +0900 (JST),
Tom Holroyd <[email protected]> wrote:
>On Mon, 8 Apr 2002, Keith Owens wrote:
>
>> System.map only contains the numeric kernel version. After all, it is
>> difficult to convert 2.4.19-pre6 to Version_132115-pre6 when symbols
>> cannot contain '-'.
>
>Well, that has an obvious solution, but modifying the Version string
>would likely break something. Adding another string would work. It
>could even be done without making the kernel image bigger. In fact,
>the Version_* symbol (and Extraversion_* symbol) could both be made
>__initdata, couldn't they?
Where the symbol's content is placed is irrelevant. System.map
contains the symbol _name_, not its _contents_. But symbol names
cannot contain the special characters that people put in extraversion.
Even mapping the special characters to '_' will not help because a lot
of people do not change extraversion when changing config and the
change of config can really move symbols around. Hence all the checks
that ksymoops does to validate symbol addresses between multiple
sources.
I have some ideas about making System.map and the kernel record which
build they refer to, including the .config data. But that is 2.5
material, after kbuild 2.5 goes in.
In article <1018246521.1534.145.camel@phantasy>,
Robert Love <[email protected]> wrote:
>Do what everyone else does and name your System.map appropriately, i.e.
>System.map-2.5.8-pre2 and then on boot symlink System.map to
>System.map-`uname -r`. Most (all?) distributions do this for you
>already.
Not even that is needed. Most if not all utilities that need a
system.map file check for System.map-`uname -r` _first_ and only
if that is not found fall back to plain System.map. So the symlink
is superfluous.
Mike.