Age | Commit message (Collapse) | Author |
|
In the systemc spec, process handles can be invalidated if they have no
children and are terminated. The implementation is not required to do
so however, and for the sake of simplicity gem5 currently does not. To
quote:
"When the underlying process instance terminates, if the process
instance has no surviving children, an implementation may choose to
invalidate any associated process handles, but it is not obliged to do
so."
Two tests have reference output which is affected by this (legal)
difference in behavior. In one case, the test creates new processes
which reuse the names of processes that have been terminated. Since
gem5 doesn't invalidate the old processes, a standard mechanism is
activated which renames the processes to something which is unique.
The other test has this same problem, and also prints the hierarchy
of processes several times during the test. In that hierarchy, the
terminated tests with no live children are still present, where in the
old reference output they've been removed.
This change updates the reference output to match gem5's behavior.
Change-Id: I363448de10080bdce01a4df92f991c67b31a2401
Reviewed-on: https://gem5-review.googlesource.com/c/14919
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
There are a number of cases where systemc leaves the decision of what
order things happen up to the kernel, and any ordering is legal and
conformant with the spec as long as it's repeatable. The reference
outputs reflect a particular choice of ordering which is implementation
specific, and while considerable effort has been made to make the gem5
ordering match the Accellera ordering, at a certain point that's no
longer practical or desirable.
This change manually updates the reference output for the tests that
haven't been excluded for other reasons which have this sort of ordering
problem. They have been individually examined, and as best as I can
tell changing the output this way does not mask any underlying error.
One or two real problems were discovered in addition to the ordering
issues, and those were fixed in earlier changes.
Change-Id: I915269998de3f33d5ab5d1fd754a830fd620184d
Reviewed-on: https://gem5-review.googlesource.com/c/14918
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
We were previously running them from the current directory to start
with, and then having the config script switch to the build directory.
That worked, except when output streams might be opened as part of the
global constructors which would run before the config script.
This change makes us start from the build directory directly, making
the switch in the config script unnecessary and ensuring that no files
leak outside of the build when running tests.
Change-Id: I484168793bfc5abc4e5631fb3468733fb9d829af
Reviewed-on: https://gem5-review.googlesource.com/c/14519
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This will prevent some (but not all) output files the tests generate
from ending up outside the build directory. Because some output file
streams are constructed as global objects, their paths are resolved
relative to the CWD when gem5 starts, before the config script has a
chance to change it.
Subsequent changes will make verify.py should make gem5 start with the
correct working directory, cleaning up the remaining leaking files.
Change-Id: I75a1256719dab4c98ab868c209d09b9dcdabb458
Reviewed-on: https://gem5-review.googlesource.com/c/14518
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This ensures that those files will be available when running the test
relative to its build directory.
Change-Id: If775ca328b3e1165baa968e4b39c36db0172837c
Reviewed-on: https://gem5-review.googlesource.com/c/14517
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This file lists additional files beyond the sources that the test
relies on, like files it uses when running.
Change-Id: Ifc4958b26eed08689e0e72bd87f84388dbcf1898
Reviewed-on: https://gem5-review.googlesource.com/c/14516
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
That's now handled automatically when the native systemc API is
enabled.
Change-Id: If1f88929af335a40554a9fd8df6f68aa1a4c0ba4
Reviewed-on: https://gem5-review.googlesource.com/c/14398
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These no longer cause any of the tests to break, so there's no reason
to filter them out.
Change-Id: I9c0b25fc42eb3060ac7d6d6a46ded130227c302d
Reviewed-on: https://gem5-review.googlesource.com/c/13396
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ieaca025786d70c0d851eec9d1eb9f7f01b513cde
Reviewed-on: https://gem5-review.googlesource.com/c/13332
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Create and use predefined messages for channels which match the ones
Accellera uses.
Change-Id: I179214838bbd83604e50225926cdc6b5b1b16923
Reviewed-on: https://gem5-review.googlesource.com/c/13330
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This test expects to exit with an error.
Change-Id: Id0b1ae4967ad0b8a356c7a04ed5fe9eb2f3c6641
Reviewed-on: https://gem5-review.googlesource.com/c/13324
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Create and use predefined messages for core which match the ones
Accellera uses.
Change-Id: I05b1398933f753946d5917f39d0f39c7cb45ed9f
Reviewed-on: https://gem5-review.googlesource.com/c/13323
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These arguments were originally just to make sure arguments could be
successfully passed to sc_main, but serve no intrinsic purpose. There
are some tests which can accept command line arguments to customize
how they run, and having nonsense arguments confuses them and makes
them behave incorrectly.
Change-Id: Ib328edb12e01a97dca778bbf45b10e91dd8c07a6
Reviewed-on: https://gem5-review.googlesource.com/c/13317
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The golden reference output for the test was to throw an error which
is clearly not at all related to the test (it was about immediate
self notifications while the test never calls any form of notify())
and which would happen significantly before the end of the test,
negating all the other behaviors and checks which would happen after
that point.
Since it strongly looks like the reference output was updated in error,
and because other very similarly structured tests are expected to run
silently except for printing "Success" at the end (which it does when
run under gem5), this change manually updates the golden reference
output to reflect what appears to be correct.
Change-Id: I9cde81c28774049653d60f1ffd37a2fae875b522
Reviewed-on: https://gem5-review.googlesource.com/c/13315
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Iec3b10b0251a7a343b81540f524427e98031577a
Reviewed-on: https://gem5-review.googlesource.com/c/13308
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
If an exception escapes sc_main, Accellera catches it and feeds it
into the report handler, telling it to run the catch actions. This
seems like it sets up lots of dangerous scenarios, and also makes a
vital error detecting path more complex and error prone.
On the other hand, it makes one of the tests pass.
Change-Id: I7f9d07e01e63c7abeee903febe2e434041ec49a4
Reviewed-on: https://gem5-review.googlesource.com/c/13307
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I585e34c4a666103af16ff1675701b61122822b55
Reviewed-on: https://gem5-review.googlesource.com/c/13299
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This typo was added purposefully to match Accellera's output, but then
it was discovered that some test's golden output had the typo, and some
didn't. That must mean that not all tests have up to date output, and
that Accellera couldn't possibly pass all of their own tests.
To resolve this conflict, this change fixes the typo and manually
updates all the golden output.
Change-Id: I3d80f74ff21e844609e7bde5dfcd99fc56c085b0
Reviewed-on: https://gem5-review.googlesource.com/c/13204
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This includes the nonstandard SC_NO_WRITE_CHECK #define which the
Accellera tests use and depend on.
Change-Id: I106c4c16160325725a00d5c337047251817dca32
Reviewed-on: https://gem5-review.googlesource.com/c/13203
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Something the Accellera implementation does which would be good to do
in the gem5 implementation is to create a base class for sc_signal
which isn't templated, and which holds the common/non-type specific
versions of the various sc_signal methods. This will reduce code
redundancy and binary size, and also let us hide more code in .cc
files so that it's less likely we'd need to recompile model code to
fix a bug.
Also, since this all uses of sc_channel_warn_unimple have now been
eliminated, remove that function.
Change-Id: Ia574647c034e7136093c2047b69de725ac34f52f
Reviewed-on: https://gem5-review.googlesource.com/c/13200
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ifbc27a3134730a95ecdb79c588c4d7fe6e889046
Reviewed-on: https://gem5-review.googlesource.com/c/13192
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
In the Accellera implementation, every time a delta cycle is traced a
check is done to see if the user has been told what the pseudo timestep
is. To avoid doing that check over and over, we'll leave that out and
tell the verify.py to ignore that message in the reference output.
Change-Id: I825f05394dccf03e951d29561a11c3cc6d4bcda7
Reviewed-on: https://gem5-review.googlesource.com/c/12969
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Method processes aren't allowed in an sc_join.
Change-Id: I5c8421a396dbe261645a074df514f69fc652c9c8
Reviewed-on: https://gem5-review.googlesource.com/c/12968
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
That function is only allowed when running a thread or cthread.
Change-Id: Idf98b70018169d4f724aa8168f3c4e8161f0b83d
Reviewed-on: https://gem5-review.googlesource.com/c/12967
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ie525a1624a6496a51277fb984cbfeec21eb79749
Reviewed-on: https://gem5-review.googlesource.com/c/12966
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ib0c14a5c7dad37b33d61c9b406f6b84121d94e46
Reviewed-on: https://gem5-review.googlesource.com/c/12965
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The reference output skips the first 7 lines which have volatile info
like the current time.
Change-Id: I9c173ff3903982a07349ca6957ab25e07bdf8e54
Reviewed-on: https://gem5-review.googlesource.com/c/12824
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
In the generic (non-console output) output checker, a variable should
have been called self.test, but was called self.text.
Change-Id: I2518d6ff01c51fc195eef2b61e987d1b3104c89b
Reviewed-on: https://gem5-review.googlesource.com/c/12817
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I06e3484176c0c06daa28f7be0ed8437b3b15ddb2
Reviewed-on: https://gem5-review.googlesource.com/c/12816
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Id1a3fd2ded224bbe94a4a65e0acf34a3547aedcc
Reviewed-on: https://gem5-review.googlesource.com/c/12813
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This warning shouldn't make a test fail, but it's still useful to keep
around.
Change-Id: I9ebdbec804e11445edb82fa824ee0a6bce5943b0
Reviewed-on: https://gem5-review.googlesource.com/c/12812
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I499cde0d0eb45ba3287a8719174e1c794c1fb634
Reviewed-on: https://gem5-review.googlesource.com/c/12810
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ic23865d9c22909bb7482223548dbc7a46c356920
Reviewed-on: https://gem5-review.googlesource.com/c/12623
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
By centralizing module callbacks, the gem5 module class knows when
different stages of the simulation are happening and can do it's own
extra checks. It also compartmentalizes modules more since the kernel
object doesn't have to reach into them to enumerate ports and exports.
Change-Id: I55887284af9c05150fe9d054f5b6147cad6092a1
Reviewed-on: https://gem5-review.googlesource.com/c/12610
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I8291f5f32fb96c42f75521385cdf14c50243860f
Reviewed-on: https://gem5-review.googlesource.com/c/12603
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change the defaults in verify.py to be more like how I've been running
it. This is as close of an approximation as I have to how someone else
would want to run it manually. When run as part of a script, it's less
cumbersome to have to add extra arguments.
Change-Id: Ibd7c7168a38aa5c014ab5c1246c9617c7358e4f9
Reviewed-on: https://gem5-review.googlesource.com/c/12602
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This change tightens up exception catching and makes gem5's systemc
code react to exceptions more in line with the Accellera
implementation. This prevents exceptions from being caught by the
pybind11 integration which makes it very difficult to see where an
exception came from, and makes the output differ by including a
(mostly useless) backtrace.
Change-Id: I7130d53a98fadd137073d1718f780f32f57c658c
Reviewed-on: https://gem5-review.googlesource.com/c/12601
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The golden output for tests doesn't distinguish between stderr and
stdout, and by only comparing against stdout we have to throw away
errors which would be good to verify we get right. Also the tests
sometimes send output to stderr for no apparent reason, requiring
manually patching the tests.
This change adds filters for two messages which used to go to stderr
in gem5 but now show up in the diffs, one that just says the simulation
is starting, and the other for warns of unimplemented functionality.
The second warning should be turned on at some point so we make sure
everything the tests touch works and they don't just work by
coincidence, but for now it introduces a lot of noise among otherwise
passing tests.
Change-Id: I3b14f7807af561a79d6e0ca87aff1ab6051be596
Reviewed-on: https://gem5-review.googlesource.com/c/12600
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
It's possible for a test to generate a warning or error in the middle
of a line of output. The previous filter generator function would
create a filter which would only detect those messages which started
at the beginning of a new line.
Change-Id: I40372dc33049df84f3111e4d63a6619db97dcaa3
Reviewed-on: https://gem5-review.googlesource.com/c/12597
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
cerr goes to simerr, but we compare simout against the golden output.
Change-Id: I9270866a92dd06a23d47c1964dacc4872030f30d
Reviewed-on: https://gem5-review.googlesource.com/c/12470
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I9e61a034d7f71bc9b1f28cb976ae8b17d6f37612
Reviewed-on: https://gem5-review.googlesource.com/c/12465
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ia5e22000449e233a079d8ba7d777a3d030138a44
Reviewed-on: https://gem5-review.googlesource.com/c/12464
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
One of them, systemc/kernel/sc_time/test07, should fail, but it should
fail from an error check and not a floating point exception like it
currently does.
Change-Id: I8c8f3c0aac5a5061780a248bde5f6de2feeecc8c
Reviewed-on: https://gem5-review.googlesource.com/c/12462
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Id967719803b5b306792c9fe6e6ddd36c36e09a88
Reviewed-on: https://gem5-review.googlesource.com/c/12460
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This test purposefully fails with an error.
Change-Id: I305a186ee076ff4e63ee82c69c27ce85dabc8fdd
Reviewed-on: https://gem5-review.googlesource.com/c/12459
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Those lines are sensitive to the paths to the test files and are even
redacted in the golden reference output, presumably for that reason.
Change-Id: I9fbd94c1b6d9d4e76397e84a4175d326f27b6e4d
Reviewed-on: https://gem5-review.googlesource.com/c/12451
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Some of the details of these messages would be annoying to match
exactly, and the error messages in gem5 go to simerr which isn't
being checked.
Change-Id: If80b124dd99987e205ccaf81d313d35df4191252
Reviewed-on: https://gem5-review.googlesource.com/c/12449
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These tests purposefully fail when they run, so a return code of 1
should be considered successful.
Change-Id: Ia4ef0469ed946d26a767805ca2d0acd734f1aec9
Reviewed-on: https://gem5-review.googlesource.com/c/12448
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Some tests expect to fail. For those tests (and only those tests) we
need to tell verify.py that it's ok if their exit status isn't 0. Also
if those tests *don't* fail, then that will also be flagged as an
error.
This is done by adding an expected_returncode file into the test's
source directory which holds what the expected return code should be.
Change-Id: I239a28e1d98dd3f76b71028660e492f675a0b3cb
Reviewed-on: https://gem5-review.googlesource.com/c/12446
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The various phases assume there are at least some tests, and if there
are none they may try to run malformed commands.
Change-Id: I041d35c504da57b830c490651ab1b3c98e0288ca
Reviewed-on: https://gem5-review.googlesource.com/12273
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|