This was incorrectly kept as `http://dist.gem5.org/dist/develop` in the
v21.0.0 release of gem5. The `dist/develop` directory is used by the
develop branch, not by gem5 releases. This change updates the URL to
point towards the currect v21-0 branch, which will remain stable and
contain resoruces always compatible with the v21-0 release.
Change-Id: I5d9a9497cebffa91f08be253f1637e11e0d5e62c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44725
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This has two purposes. First, SCons assumes that once you call
Configure, you won't set up the environment the Configure is based on
until after you get the environment back from it again with
conf.Finish(). We get away with this when the cache mode for config
tests is not "force", since Configure just reuses the environment we
pass in, and any changes we make are immediately communicated between
the two.
If the cache mode *is* "force" though, SCons modifies the decider so
that everything the conf environment goes to build looks like it's out
of date. It does that by cloning the original environment, and then
using that clone to do its tests. That causes a problem because we have
a long lived "conf" object and make further changes to main, and since
the two environments are now separate the one in conf doesn't see those
updates.
Second, and more subtly, we export our "main" and "env" environments so
that other SConsopts and SConscript files can use them and define things
in them. The way Configure is designed, if the config caching mode is
"force", then it will create a new environment, and then that
environment will replace what the, for instance, "main" variable points
to when "main = conf.Finish()" is executed.
Unfortunately, if we've already Export()-ed main, we've exported what
the "main" variable pointed to at that time. Our view of "main" will
track with the value that conf.Finish() returned, but since that
construction environment is mearly derived from the main we Exported and
not actually the same thing, they have diverged at that point and will
behave independently.
To solve both of these problems, this change modifies the
gem5_scons.Configure() method so that it's a context manager instead of
a regular function. As before, it will call Configure for us and create
a configuration context, which it will yield as the "with" value. When
the context exits, all the variables in the context Finish() returns
will be shoved back into the original context with Replace(). This isn't
perfect since variables which were deleted in the environment (probably
very rare in practice) will not exist and so will not overwrite the
still existent variable in the original dict.
This has several advantages. The environment never splits into two
copies which continue on independently. It makes the lifetime of a
configuration context short, which is good because behavior during that
time is tricky and unintuitive. It also makes the scope of the context
very clear, so that you won't miss the fact that you're in a special
setting and need to pay attention to what environment you're modifying.
Also, this keeps the conceptual overhead of configuration localized to
where the configuration is happening. In parts of the SConscripts which
are not doing anything with conf, etc, they don't have to modify their
behavior since no configuration context is active.
This change is based on this change from Hanhwi Jang who identified this
problem and proposed an initial solution:
https://gem5-review.googlesource.com/c/public/gem5/+/44265
Change-Id: Iae0a292d6b375c5da98619f31392ca1de6216fcd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44389
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Hanhwi Jang <jang.hanhwi@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
An expression in that library intended to create a bitmask by checking
if a bit should be set, and then using ?: to select between a bitmask
with that bit, or 0. Unfortunately | is higher precedence than ?:, and
so 0 would be |-ed with the condition of the next ?: instead. This CL
fixes the bug by adding some parenthesis.
Change-Id: Ib7e06f261e07a6ad00b9a96939d07b64c3a50409
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40954
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is in the Accellera version of systemc, used when gem5 is built
into systemc as a black box. std::gets was depdecated in c++11, and
removed entirely in c++14. Since gem5 has moved to c++14, this can't be
brought in with "using" in that header. More recent versions of systemc
from Accellera may have this fixed, and it's pretty bad practice to have
a universal header file squash unrelated namespaces like that in the
first place.
Rather tha update all of this copy of systemc, this change just makes
the smallest adjustment possible to get things to work again.
Change-Id: I8a95665d4b5d49ffc014097714cf2e602bf9b937
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently run regressions with the following command line
./main.py run [...] <directory>
Where <directory> is the positional argument pointing to the tests root
directory: Testlib will walk through the directory and load every
testsuite it encounters in its path.
./main.py run [...] <directory1> <directory2> ...
Allowing testlib to load tests from multiple directories will make it
possible to load out of tree regressions (living in an EXTRAS repository
for example)
JIRA: https://gem5.atlassian.net/browse/GEM5-905
Change-Id: I802d8753a18f4dfb00347252f031b5438e9be672
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40136
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This should help reduce warning spew when building with newer compilers.
The pybind11::module type has been renamed pybind11::module_ to avoid
conflicts with c++20 modules, according to the pybind11 changelog, so
this CL also updates gem5 source to use the new type. There is
supposedly an alias pybind11::module which is for compatibility, but we
still get linker errors without changing to pybind11::module_.
Change-Id: I0acb36215b33e3a713866baec43f5af630c356ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40255
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Note:
Some less frequently needed CSR registers (e.g. hpm and pmp registers)
are commented out on purpose. Instructions to add them back are
described in remote_gdb.hh comments. This is to avoid spamming the
remote GDB log when using `info reg all`.
Changes:
1. Added GDB XML files to the ext/ directory (mostly from QEMU)
2. Modified RiscvGdbRegCache
- struct r: added CSR registers
- getRegs, setRegs: reading / setting CSR registers
3. Modified RemoteGDB
- availableFeatures: indicate support for XML registers
- getXferFeaturesRead: return XML blobs
Change-Id: Ica03b63edb3f0c9b6a7789228b995891dbfb26b2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38955
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The log_call helper is now accepting a time parameter (dictionary). If
the param is not None, the function will fill the timing indications
(user and system time) for the TestCase.
There are some TestCases whose user time is not of our interest; for
example we don't really care about the cpu time of a stdout diff
(MatchStdout tests). In those cases the resulting cpu time in the
generated JUnit file (results.xml) will be 0.
JIRA: https://gem5.atlassian.net/browse/GEM5-548
Change-Id: I53c1b59f8ad93900aeac06197e39189c00a9053c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32653
Tested-by: kokoro <noreply+kokoro@google.com>
Added utility class `TimedWaitPID` which monkey-patches os.waitpid()
with a functor that has the same signature, but calls os.wait4()
instead. This allows the process's user and system CPU time to be
obtained from the OS when using APIs (such as subprocess) which use
os.waitpid() internally.
The process CPU time is stored within the functor and can be read back
later by calling TimedWaitPID.get_time_for_pid().
JIRA: https://gem5.atlassian.net/browse/GEM5-548
Change-Id: I9ebe9ca1241a4f28c90ad31f672f32ac52786664
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32652
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Log object should remain being a singleton throughout the program.
The current code creates multiple Log objects, which at least
causes the issues of missing outputs in stdout.
E.g., "Logging call to command", which logs which command is
being called in a subprocess, is missing from stdout.
Change-Id: I96c5dd79c4f14e0a013c15d42d202397488d56b6
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33715
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
We were downloading resources to various different locations, for no
real reason. This standardizes the process. From this commit onwards,
all testing resources are downloaded to `tests/gem5/resources` by
default. This may be overriden via the `--bin-path` TestLib argument.
Note: In order to do this I have changed the meaning of the `bin-path`
TestLib argument slightly. Previously the `bin-path` assumed a flat
(non-existant) hierarchy. A simple directory of local resources. This
new bin-path functionality maintains logical sub-directories. This is
technically an API change and will be noted in the release notes.
Change-Id: I4df85c121fa65f787fd71f03d74361afea121380
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33145
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Compiling gem5 with dramsim2 included fails due to some inconsistencies in
including SimObjects. In this patch this issue is fixed along with
temporarily disabling -Werror=nonnull-compare in CCFLAGS. Also, the remote
for cloning dramsim2 has been changed.
Change-Id: Ia24095150d026d736352aaf0d735b7554ede10bb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31434
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The sandbox module is providing a sandbox environment for
a specific TestCase via the multiprocessing package.
This isolation/complexity is not strictly needed as testlib is already
forking a new process via subprocess. As it is now, a TestRunner will
generate:
TestRunner -> multiprocessing.Process -> subprocess.Popen
(2 generated procs)
With this patch we are removing the intermediate layer
TestRunner -> subprocess.Popen
(1 generated proc)
JIRA: https://gem5.atlassian.net/projects/GEM5/issues/GEM5-533
Change-Id: Icd5cadbe316653a9269ab098ec4c07f21b864ad3
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30215
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
