When extending a SimObject by subclassing, if you don't call
`super().__init__()` you get a confusing infinite recursion error. The
infinite recursion occurs because SimObject overrides `__getattr__`. So,
if an attribute is accessed that is set in SimObject.__init__ but that
function hasn't been called there's a problem.
This patch adds another member variable to track if __init__ has been
called. This member variable is set to False in the *meta class* so
that it will always be available, even if __init__ has not been called.
There is one check for whether init has been called in the __getattr__
function. This is where I have experienced prior issues. This function
could be called from other SimObject functions, if needed.
With this change, a helpful error is shown telling the user to be sure
to call super().__init__ in the specific class that is missing the call.
Note: I have been bitten by this an embarrassing number of times. A
helpful error message would have saved me many hours.
Change-Id: Id919c540b23fc2783e203ef625bce3000ba808a9
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51568
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this commit, on assigning NULL to an 'attr' that is a SimObject,
the corresponding children SimObject was not set to NULL.
This makes some SimObject being initialized in the c++ world
even if they are not needed.
This commit set the children to NULL in that case.
Change-Id: I2030d9d1b80c020fa28e50c0eca4f87b756763d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51647
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
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 device and the file it's in have the same name as one already
defined by arm. This is basically ok when those are mutually exclusive,
but can't coexist when both ISAs can be included at the same time. This
is because the file name would put them both under
m5.objects.VirtIOMMIO, and the name of the object itself would conflict
when importing * from m5.objects.
Change-Id: I558676b7d64cc68adb2d81b070a1816aa0bea6ba
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50335
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Prior to this patch the downloader would download resources to the
user's pwd unless explictly stated otherwise. This patch checks the
environment variable `GEM5_RESOURCE_DIR` for a resource directory and if
this is not set, it will default to `~/.cache/gem5`.
Change-Id: I672479a37342d2a97e8ac6404775f3fd969b07b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51369
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It's really a part of the build system and not part of gem5, and so it
should probably live outside of the main tree. It would be confusing to
have a bunch of python scripts which don't end up inside gem5 alongside
a bunch of ones that do in src/python.
The directory is called build_tools instead of build so it doesn't get
confused with an actual build output directory.
Change-Id: Ie12475a15517508dc2044f0ca4db71a601b7ab6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49393
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The new c++ wrapper is called gem5py, and will run any python script
using gem5's embedded python interpreter. The "marshal" functionality is
split out into a separate python script gem5py can run.
The command line for gem5py should look like this:
gem5py ${SCRIPT TO RUN} ${ARGS TO THE SCRIPT}
So, for instance, to marshal a file called foo.py, the command line
might look like this:
gem5py python/marshal.py foo.py
Also, this change reorders the sources for the python embedding action
and limits the max_sources for Transform() to 1, so that it just shows
the python file being embedded and not gem5py or the marshal.py script.
Those are still sources so dependency tracking works correctly, but they
are also implied and just add visual noise to the build output.
Change-Id: I7ae6bd114973ae44c3b634884b6dafc6577e0788
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49392
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Version 0.11 was actually the first version of ipython which even
supported python 3 at all, as far as I can tell. Because we have a
requirement to use at least python 3 (and not just 3.0 at that), we can
assume that the user must be using at least version 0.11 of ipython.
That means we can remove code which supported older versions.
Change-Id: I7f88aae9f64f6c6f027be52741cda0686f5ca5be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50709
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There was some code at the end of main.py which would let you run it
directly. This would parse options passed to the script, and show you
what they equaled.
Also, the "main" function would optionally let you pass in options to
override whatever it would find with parse_arguments. This is no longer
used.
Change-Id: Ib0effa7ac2b4a51b68994372a7c7fcf1c9b4dc13
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50707
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Expand exclude to work with an AddrRange or AddrRangeList, define
versions to exclude both from an AddrRangeList, and make all available
through subtraction operators. Add -= operators for AddrRangeList with
another AddrRangeList or AddrRange.
Change-Id: Ic48f0c45a4809dbc51e1d3133e8319134aabe29e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50347
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
We go through the trouble of defining an AddrRangeList typedef, but then
we don't use it consistently and use std::vector<AddrRange> instead.
This change converts the exclude method from using
std::vector<AddrRange> to AddrRangeList, and also adds a constructor
which takes an AddrRangeList.
Because there is a lot of code which uses the std::vector based
constructor, this change does not remove that method.
Change-Id: I1a03b25990025688aa760a67d3e7a2e8141384ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50344
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
This complements the --redirect-stdout and --redirect-stderr options and
supresses the message about where those streams are being redirected
which print to the original stdout.
Usually this is very helpful since it lets you know where to look for
simulator output. If you're running gem5 in an automated environment
like our testing framework however, the file name is a random temp file
which will be deleted as soon as the test is finished running.
The --silent-redirect option can be used in these particular scenarios
to, for example, avoid lots and lots of useless lines in the test output
naming files that no longer exist.
Change-Id: If56b61567b3d98abd9cc9d9e9d661ea561be46f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50588
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 'components_library' name was always a placeholder. A more accurate
name would be the 'gem5 library'. This is analogous to standard
libraries shipped as part of programming languages. Over time this will
begin to incorporate more commonly used code at the Python configuration
script level. Most of the former 'components_library' is now in
'gem5.components'.
Change-Id: I5927db7004c43b29c39e7767da3f779627081618
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49691
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some debate on how best to distribute the components
library. This change builds the components library into the gem5 binary.
The components library will now function similar to the `m5` library.
There is no need for awkward imports or obtaining the library from some
third-party source.
Additional incorporated in this patch:
* Added `__init__.py` to the Python modules.
* Fixed a typo in the `abstract_ruby_cache_hierarchy.py` filename.
* Ensured that imports within the library are relative.
Issue-on: https://gem5.atlassian.net/browse/GEM5-1023
Change-Id: I3988c8710cda8dcf7b21109a2cf5c3f1608cc71a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49690
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Austin Harris <mail@austin-harris.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It is currently not possible to call m5.fork when the simulator is
running in with multiple parallel event queues. The POSIX standard
have very weak guarantees when forking a process with multiple
threads. In order to use fork correctly, we need to ensure that all
helper threads servicing event queues have terminated before the fork
system call is invoked.
There are two ways this could be implemented: 1) Always terminate
helper threads when taking a global simulator exit event, or 2)
terminate helper threads just before fork is called from Python.
This change implements the second strategy since the KVM-based CPUs
currently assume that TIDs don't change unless there is a fork event.
Change-Id: I22feaecd49f7f81689b43185d63a8f14428bed63
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50408
Reviewed-by: Austin Harris <mail@austin-harris.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The compileDate and gem5Version fields are used in only one place,
gem5's python main function. These fields are the remaining difference
between the "fake" defines.py provided by the SimObject importer, and
the real one composed later. It makes sense to exclude them in the
"fake" version since those values come from c++, but it would feel like
an arbitrary and unexpected difference to people trying to use it.
Change-Id: Ie344765bf7c8063197da24f5b55f762379deff94
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48380
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Create an AllFlagsFlag class which inherits from the CompoundFlag class.
This class is a singleton, and the SimpleFlags install themselves in it
instead of having SCons collect them.
The allFlagsVersion global variable was supposed to be for debugging
according to a comment, but was actually an important part of the "All"
flags inner workings. It was not exposed in the header, but was
redefined/pulled through in src/python/pybind11/debug.cc. The
AllFlagsFlag class now tracks that value, and it can be accessed without
reaching behind the curtain.
This also somewhat decentralizes the debug flag building process in
SCons. The debug/flags.cc still includes all flags at once which
centralizes them, but at least now the "All" flag won't also.
Change-Id: I8430e0fe9022846aade028fb46c80777169a2007
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48370
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
In the SConscript, there is a special importer which enables importing
embedded code using various m5.* paths. This was implemented using an
API which has been deprecated and replaced in more recent versions of
python.
Change-Id: I5900f269af48befbcedcb9d25353f04f6297ce9d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48363
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
The function will return the absolute path of the gem5 repo
hosting the m5 library.
One of the use of this helper is to effectively refer/import
gem5 modules from EXTRAS repositories.
If I wanted to import the Ruby module from configs/ruby I could
do that with:
from m5.util import addToPath, repoPath
configs_path = os.path.join(repoPath(), configs)
addToPath(configs_path)
from ruby import Ruby
This isn't an out of tree scripts utility only: most of our configs are
currently relying on doing relative backward imports and could be ported
to use the repoPath utility:
addToPath(../..) is quite a common pattern
This makes the dependencies difficult to read/track and a bit fragile
as it all relies on the relative position between modules.
Change-Id: I26f6ef34b44f20903cc1b6248330b6156378f40b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49083
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Now that we're using c++17, the type_traits with a ::value member have
a _v alias which reduces verbosity. Or on other words
std::is_integral<T>::value
can be replaced with
std::is_integral_v<T>
Make this substitution throughout the code base. In places where gem5
introduced it's own similar templates, add a V alias, spelled
differently to match gem5's internal style.
gem5: :IsVarArgs<T>::value => gem5::IsVarArgsV<T>
Change-Id: I1d84ffc4a236ad699471569e7916ec17fe5f109a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48604
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
