Very Computer

I have been running Linux for a few months now and I must admit, I
got*y.  I broke the cardinal rule... If it ain't broke, don't fix
it.  Well, I tried to upgrade kmem-ps-1.3.95+ and I have had very
limited success.  It compiled fine.  Installed fine.  Needless to say,
nothing ran fine.  How's 2 out of 3?  Anywayz, enough *, to the
details...
    I am running Slackware 3.0 w/ kernel 1.3.98 (I updated that in an
attempt to fix my problems).  In the README it says that after
compiling, one should run 'ps -U' to create the psdatabase.  Upon
running:

dread:/usr/src/kmem-ps-1.3.95+# ps -U

    All I got wuz...

/usr/src/linux/System.map: bad magic number

    It also says that you can specify the system binary and the swap
device/file as arguments like so:  ps -U /usr/src/linux/tools/system
/dev/swap   Well, I had no /dev/swap so I made a symbolic link to
/dev/hdb2, where my swap partition is.  I then tried to figure out
where /usr/src/linux/tools/system was.  I had no tools/system in my
linux directory.  In the NEWS file it mentioned being able to use the
System.map file but I didn't read that before I attempted copying
vmlinux to tools/system and I got the same thing: bad magic number.
    Now all those little usefuls such as 'ps' and 'w' and 'top' simply
refuse to cooperate no matter how much coercion is attempted.  I have
been reduced to a slobbering newbie and am sufficiently humbled. I now
publicly beg help.  Thanks ahead of time...
--

-Saadiq Rodgers-King

* http://www.veryComputer.com/~saadiqr/

Quote:>    All I got wuz...

>/usr/src/linux/System.map: bad magic number

I'm guessing you upgraded your binutils recently.

System.map is created by running nm on vmlinux, grepping out a
few things, running thruogh sort, and a few other things.  

Older versions of nm created a 32 bit entry for the first column
of System.map.  Current versions create 64 bit.  Many
applications had hard coded their routines that analyze
System.map to expect 32 bit entries (in short, when reading each
line, they used scanf with %8x rather than just %x).  

Now, many programs also checked against a few specific things in
the first couple of lines, to make sure System.map was in a
correct format before reading the whole thing.  I assume this
step is failing with ps -U.  There really isn't any "magic
number" with System.map, but more of a magic format.  If you're
sufficient with C, you can probably go in and tweak the code
(preferably to something that works with both 32-64 bit entries).

The dosemu routine for validating System.map seems to work well.
If you have that handy, may want to check that out for ideas.

Alternatively, you could run System.map through sed and strip the
first 8 chars off of each line, but that's not a very good
solution (need to do that every time you build a kernel).  You'd
probably want to create a patch to send back to kmem-ps author,
and get your name on the package as a contributor.  ;->

mrc
--
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly


    We are all of us living in the shadow of Manhattan.  -- Watchmen