Discussion:
Trouble getting started with gem5
(too old to reply)
Eliot Moss
2011-12-28 18:30:26 UTC
Permalink
This afternoon I followed the instructions for installing and doing the simplest
build (scons build/ALPHA_SE/tests/debug/quick), insuring that I have the prerequisites:

scons: 1.2.0
swig: 1.3.29
python: 2.4.3
gcc: 4.1.2
zlib: 1.2.3
m4: 1.4.5

linux: 2.6.18

I got complaints from gcc about a couple of .hh files defining virtual functions
while having a non-virtual destructor. In resource_pool.hh I added the keyword virtual to the
existing destructor declaration; in output.hh I had to declare the destructor,
as virtual, and give it an empty body. There was also a problem with event-wrap.cc;
two cases of $self were not liked by gcc, so I changed them to self, and the system
built. It passes most tests (with statistics variations to be expected), but
produced the failures below. (More comments after the scons output.)
Should I be concerned? What should I do?

Regards -- Eliot Moss

Running test in build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-atomic.
build/ALPHA_SE/gem5.debug -d build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-atomic
-re tests/run.py build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-atomic
Redirecting stdout to build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-atomic/simout
Redirecting stderr to build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-atomic/simerr
scons: *** Error 1
M5 exited with non-zero status 1
***** build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-atomic FAILED!

Running test in build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-timing.
build/ALPHA_SE/gem5.debug -d build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-timing
-re tests/run.py build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-timing
Redirecting stdout to build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-timing/simout
Redirecting stderr to build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-timing/simerr
scons: *** Error 1
M5 exited with non-zero status 1
***** build/ALPHA_SE/tests/debug/quick/20.eio-short/alpha/eio/simple-timing FAILED!

Running test in build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-atomic-mp.
build/ALPHA_SE/gem5.debug -d build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-atomic-mp
-re tests/run.py build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-atomic-mp
Redirecting stdout to build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-atomic-mp/simout
Redirecting stderr to build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-atomic-mp/simerr
scons: *** Error 1
M5 exited with non-zero status 1
***** build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-atomic-mp FAILED!

Running test in build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-timing-mp.
build/ALPHA_SE/gem5.debug -d build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-timing-mp
-re tests/run.py build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-timing-mp
Redirecting stdout to build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-timing-mp/simout
Redirecting stderr to build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-timing-mp/simerr
scons: *** Error 1
M5 exited with non-zero status 1
***** build/ALPHA_SE/tests/debug/quick/30.eio-mp/alpha/eio/simple-timing-mp FAILED!

Running test in build/ALPHA_SE/tests/debug/quick/50.memtest/alpha/linux/memtest.
build/ALPHA_SE/gem5.debug -d build/ALPHA_SE/tests/debug/quick/50.memtest/alpha/linux/memtest -re
tests/run.py build/ALPHA_SE/tests/debug/quick/50.memtest/alpha/linux/memtest
Redirecting stdout to build/ALPHA_SE/tests/debug/quick/50.memtest/alpha/linux/memtest/simout
Redirecting stderr to build/ALPHA_SE/tests/debug/quick/50.memtest/alpha/linux/memtest/simerr
scons: *** Error -6
M5 terminated with signal 122
***** build/ALPHA_SE/tests/debug/quick/50.memtest/alpha/linux/memtest FAILED!

scons: done building targets.


Perusing the simerr/simout files I see:
EioProcess not defined (python), which happens for the status 1 cases above

For the -6 case, simerr contains:
gem5.debug: build/ALPHA_SE/mem/cache/cache_impl.hh:1247: void Cache<TagStore>::handleSnoop(Packet*,
typename TagStore::BlkType*, bool, bool, bool) [with TagStore = LRU]: Assertion
`!pkt->memInhibitAsserted()' failed.
Program aborted at cycle 409893

That's it ... EM
Eliot Moss
2011-12-28 18:37:06 UTC
Permalink
I've seen in the message archives a note about EioProcess,
which I can ignore since it comes from the "encumbered"
package. But the other error is slightly concerning ...

Eliot
Steve Reinhardt
2011-12-28 19:04:12 UTC
Permalink
Hi Eliot,

- There are known issues with gcc 4.1; we recommend gcc 4.3 or higher (see
http://gem5.org/Dependencies#External_tools_and_required_versions)

- You're right about the EioProcess errors; these are regression tests that
require the "eio" module that's used only for compatiblity with
Simplescalar EIO traces. Unfortunately our regression system isn't smart
enough to recognize up front that you haven't compiled them in and then
skip them. A new regression test system is high on our wish list, though
no one is actively working on it.

Steve
Post by Eliot Moss
I've seen in the message archives a note about EioProcess,
which I can ignore since it comes from the "encumbered"
package. But the other error is slightly concerning ...
Eliot
______________________________**_________________
gem5-users mailing list
http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
Eliot Moss
2011-12-28 20:18:28 UTC
Permalink
Ok. I moved to gcc 4.4., using CC=gcc44 CXX=g++44 in the
scons command line. I stil get the funky thing about
$self from event.i. I removed the $ from those in event.i
and that part builds find. There is a line in pyrun.swg
in the swig I have installed that fails to put a (char*)
before "__dict__" as gcc 4.4. seems to demand. So I edited
that file as well.

Now I get a clean build. I still get the EioProcess
failures, of course. But I still get that other
memtest error.

At this point I won't worry about it until I see
problems with "real" builds ... Eliot
Steve Reinhardt
2011-12-28 20:53:08 UTC
Permalink
I noticed your swig version is also older than what's recommended... check
the link for details, as it's a bit complicated. That's almost certainly
the source of your $self problem.

As for the memtest error, are you using the main gem5 code or gem5-stable?
The latter tends to be more "stale" than "stable", so if that's what
you're on, that could be it. Otherwise, I'm not sure where the problem
would be coming from, as we don't run into this in our nightly regressions.

Steve
Post by Eliot Moss
Ok. I moved to gcc 4.4., using CC=gcc44 CXX=g++44 in the
scons command line. I stil get the funky thing about
$self from event.i. I removed the $ from those in event.i
and that part builds find. There is a line in pyrun.swg
in the swig I have installed that fails to put a (char*)
before "__dict__" as gcc 4.4. seems to demand. So I edited
that file as well.
Now I get a clean build. I still get the EioProcess
failures, of course. But I still get that other
memtest error.
At this point I won't worry about it until I see
problems with "real" builds ... Eliot
Eliot Moss
2011-12-28 23:50:28 UTC
Permalink
I noticed your swig version is also older than what's recommended... check the link for details, as
it's a bit complicated. That's almost certainly the source of your $self problem.
As for the memtest error, are you using the main gem5 code or gem5-stable? The latter tends to be
more "stale" than "stable", so if that's what you're on, that could be it. Otherwise, I'm not sure
where the problem would be coming from, as we don't run into this in our nightly regressions.
Steve
Thank you, Steve. With swig 1.3.31 and gem5 (as opposed to
gem5-stable) the build errors go away.

I still get the same 5 failures -- 4 eio and 1 memtest. What's
the proper way to install the 'encumbered' package? I did not
readily find anything about where to plop it into the gem5
tree.

Cheers -- Eliot
Eliot Moss
2011-12-29 02:06:38 UTC
Permalink
Ok, I found in the FAQ about using EXTRAS to
get EIO built in ... it almost worked to build,
but I had to copy two .h/.hh files over to the
build tree by hand.

But I get the same 6 failures, 5 EIO and 1 memtest.

For the EIO failures I ask: where is anagram? Do I
also need some set of benchmarks installed?

Cheers -- Eliot
Steve Reinhardt
2011-12-29 07:35:31 UTC
Permalink
I just updated my repository and ran these two commands:
scons -j 8 EXTRAS=../encumbered build/ALPHA_SE/tests/debug/quick
scons -j 8 build/ALPHA_SE/tests/opt/quick

and got no build errors and no test failures.

This was on our regression machine, so the EIO traces are in a common
shared directory there, not in the repository. So it's no surprise that
the EIO tests failed for you. Unless you really want to use EIO traces, I
wouldn't worry about them. The fact that you had to copy the headers is
odd though; I didn't need to do that.

The memtest failure is more bothersome. Are you sure the test was rerun
after you updated to the non-stable repository? If so, it might be worth
doing a clean build (you can do "scons -c", or just "rm -rf build").

Steve
Post by Eliot Moss
Ok, I found in the FAQ about using EXTRAS to
get EIO built in ... it almost worked to build,
but I had to copy two .h/.hh files over to the
build tree by hand.
But I get the same 6 failures, 5 EIO and 1 memtest.
For the EIO failures I ask: where is anagram? Do I
also need some set of benchmarks installed?
Cheers -- Eliot
Eliot Moss
2011-12-29 14:04:59 UTC
Permalink
Post by Steve Reinhardt
scons -j 8 EXTRAS=../encumbered build/ALPHA_SE/tests/debug/quick
scons -j 8 build/ALPHA_SE/tests/opt/quick
and got no build errors and no test failures.
This was on our regression machine, so the EIO traces are in a common shared directory there, not in
the repository. So it's no surprise that the EIO tests failed for you. Unless you really want to
use EIO traces, I wouldn't worry about them. The fact that you had to copy the headers is odd
though; I didn't need to do that.
I tried again, starting from checking out gem5 and encumbered, fresh from the repo.
It seemed to make a difference to use a ../encumbered path in EXTRAS, and perhaps
to use the specific name 'encumbered' (I had renamed the directory to gem5-encumbered).
The build went through fine. My command line was:

scons CC=gcc44 CXX=g++44 EXTRAS=../encumbered build/ALPHA_SE/tests/debug/quick

The EIO tests indeed fail, but anagram isn't there so it's no surprise.
Where does it come from, by the way?
Post by Steve Reinhardt
The memtest failure is more bothersome. Are you sure the test was rerun after you updated to the
non-stable repository? If so, it might be worth doing a clean build (you can do "scons -c", or just
"rm -rf build").
memtest still fails. Here is the exact contents of simerr:

gem5.debug: build/ALPHA_SE/mem/cache/cache_impl.hh:1257: void Cache<TagStore>::handleSnoop(Packet*,
typename TagStore::BlkType*, bool, bool, bool) [with TagStore = LRU]: Assertion
`!pkt->memInhibitAsserted()' failed.
Program aborted at cycle 409893

memtest-ruby passed.

Versions of programs are:

gcc44/g++44: 4.4.4
scons: 1.2.0
swig: 1.3.31 (I can install any particular one you like instead)
zlib: 1.2.3
m4: 1.4.5
python: 2.4.3

Regards -- Eliot

PS: Since the first, most basic, build is more or less passing,
what's the next thing up that I can test?
Steve Reinhardt
2011-12-29 17:54:38 UTC
Permalink
Post by Eliot Moss
I tried again, starting from checking out gem5 and encumbered, fresh from the repo.
It seemed to make a difference to use a ../encumbered path in EXTRAS, and perhaps
to use the specific name 'encumbered' (I had renamed the directory to gem5-encumbered).
The name and whether it's an absolute or relative path really shouldn't
matter. If it bugs you, you can use the '--verbose' flag to scons to print
out the full g++ command line and see what was coming after -I before, but
if you're content that it works now, that's OK too.
Post by Eliot Moss
scons CC=gcc44 CXX=g++44 EXTRAS=../encumbered build/ALPHA_SE/tests/debug/*
*quick
The EIO tests indeed fail, but anagram isn't there so it's no surprise.
Where does it come from, by the way?
The anagram program that generates the trace is one of the tests that comes
with SimpleScalar. I don't know if the EIO trace itself came with
SimpleScalar too or if we generated it ourselves. Note that gem5 only
reads EIO traces; it can't generate them itself. This capability was very
useful for transitioning from SS to m5 way back a long time ago, but I
don't know of anyone using it in a long time. We were just discussing
dropping support for it recently, since the confusion it causes in the
regression tests seems to outweigh any benefit anyone gets from it anymore.
Post by Eliot Moss
The memtest failure is more bothersome. Are you sure the test was rerun
Post by Steve Reinhardt
after you updated to the
non-stable repository? If so, it might be worth doing a clean build (you
can do "scons -c", or just
"rm -rf build").
gem5.debug: build/ALPHA_SE/mem/cache/**cache_impl.hh:1257: void
Cache<TagStore>::handleSnoop(**Packet*, typename TagStore::BlkType*,
bool, bool, bool) [with TagStore = LRU]: Assertion
`!pkt->memInhibitAsserted()' failed.
Program aborted at cycle 409893
This is still very weird. The assertion failure is one I've seen before;
it's commonly a symptom of some corner-case coherence protocol bug. The
problem is that (1) there are no outstanding coherence protocol bugs that I
know of and (2) even i there were, the pseudo-random number generator
should be repeatable such that the fact that we don't encounter it in our
regression test means that you shouldn't encounter it either. So I'm
doubly confused. I fired up a longer run of the random tester (10M vs 100K
accesses) to ook for evidence that assumption #1 is wrong, but it also
passed. I'll fire up an even longer one, but that still leaves issue #2.
I'm perplexed. Are you running this on Linux?
Post by Eliot Moss
PS: Since the first, most basic, build is more or less passing,
what's the next thing up that I can test?
The util/regress script fires off our full regressions (compiles
gem5.debug, gem5.opt, and gem5.fast for all ISAs, runs all the 'quick'
tests using gem5.opt). It takes quite a while though. You can subset it
as you please using command-line options (util/regress --help for details).

The tests do require a number of additional binaries that aren't in the
repository though. Most of these are available from te links named "full
system files" here: http://gem5.org/Download. I see there's also a very
brief discussion here:
http://gem5.org/Introduction#Getting_Additional_Tools_and_Files. Neither
of these places mentions that you can put the files anywhere you want as
long as you set the M5_PATH environment variable to point to them... you
have to look here for that:
http://gem5.org/Compiling_M5#Installing_full_system_files. Ugh.

BTW, if you have any inclination at all to update our wiki to clarify any
issues you've run into, please don't hesitate... it would be much
appreciated.

Steve

Continue reading on narkive:
Loading...