The 'resources.json' file in gem5 resources is used to lookup resources.
The stdlib resource downloader was hardcoded to the 'resources.json'
stored in the gem5 resources stable branch. This change allows the gem5
downloader to obtain the specific resources.json.
Change-Id: Ie119ed9326b359055bf5bc347ca89336a5cc2e5d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54466
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Because the python environment may already be up and running by the time
static initializers are run, specifically when gem5 is built as a
library and loaded with dlopen, we can't rely on all of the objects
declaring python initialization callbacks having been constructed by the
time the code which would execute them runs.
To address that problem, this change keeps track of whether the
initialization has already happened when a callback is installed, and if
so, runs the callback immediately.
The original implementation also had users install callbacks by
overriding a virtual function in the PythonInitFunc class, and then
statically allocating an instance of that subclass so its constructor
would be called at initialization time. Calling the function manually if
initialization has already happened won't work in that case, because you
can't call a virtual function from a constructor and get the behavior
you'd want.
Instead, this change makes the PythonInitFunc wrap the actual callback
which is outside of the structure itself. Because the callback is not a
virtual function of PythonInitFunc, we can call it in the constructor
without issue.
Also, the Callback type has to be a bare function pointer and not a
std::function<...> because the argument it takes is a pybind11::module_
reference. Pybind11 sets the visibility of all of its code to hidden to
improve binary size, but unfortunately that causes problems when
accepting one as an argument in a publically accessible lambda in g++.
clang doesn't raise a warning, but g++ does which breaks the build. We
could potentially disable this warning, but accepting a function pointer
instead works just as well, since captureless lambdas can be trivially
converted into function pointers, and they don't seem to upset g++.
Change-Id: I3fb321b577090df67c7be3be0e677c2c2055d446
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54325
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc testing framework is not used regularly, and had bit rot and
stopped working. This change updates it so that it runs again, and all
previously passing tests pass again.
These changes were mostly in the related SConscript now that top level
targets are built a little differently and that the gem5 shared library
is no longer stored in a special construction environment variable.
verify.py also needed to be updated since warn() and info() lines now
have file and line number information in them, throwing off pre diff
filtering of gem5 outputs.
Change-Id: Ifdcbd92eab8b9b2168c449bfbcebf52dbe1f016a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54324
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The previous incarnation of this support used faults to make the CPU
reexecute the system call instruction again and again to prevent
emulating/passing through blocking system calls from blocking gem5 as
a whole. That support was accidentally removed a while ago. This new
version suspends the thread context executing the system call, and
periodically wakes it up to retry using a periodically scheduled event.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1123
Change-Id: I155fa8205d7ea45e3d102216aeca6ee1979a522f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54205
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than make each ISA include boilerplate to ignore a
SyscallReturn's value when it's marked as suppressed or needing a retry,
put that code into the SyscallDesc::doSyscall method instead.
That has two benefits. First, it removes a decent amount of code
duplication which is nice from a maintenance perspective. Second, it
puts the SyscallDesc in charge of figuring out what to do once a system
call implementation finishes. That will let it schedule a retry of the
system call for instance, without worrying about what the ISA is doing
with the SyscallReturn behind its back.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1123
Change-Id: I76760cba75fd23e6e3357f6169c0140bee3f01b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54204
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This method depended on all of the EmbeddedPyBind objects having all
been constructed already so that it would have a complete list. This
would only be true if it was called after static intialization was
complete, which is not true if python is ready to go as soon as gem5
(in library form) is loaded.
This change makes EmbeddedPyBind able to defer initialization of a
module more generically than before, so that they can wait for either
another module to be initiailized, or the _m5 package itself.
Change-Id: I6b636524f969bd9882d8c1a7594dc36eb4e78037
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54005
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54265
If there really are no c++ sim_objects in the file, then sim_objects can
be set to [] which it used to default to.
This way, if someone hasn't remembered to update their SConscript files
for the new sim_objects and enums parameters, this will give them some
indication what's wrong, rather than the build just failing later.
Change-Id: Ic1933f7b9dfff7dd7e403c6c84f1f510c8ee8c72
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54203
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This patch is modifying both TableWalker and MMU to effectively
store/use partial translations
* TableWalker changes: If there is a TLB supporting partial
translations (implemented with previous patch), the TableWalker will
craft partial entries and forward them to the TLB as walks are performed
* MMU changes: We now instruct the table walker to start a page
table traversal even if we hit in the TLB, if the matching entry
holds a partial translation
JIRA: https://gem5.atlassian.net/browse/GEM5-1108
Change-Id: Id20aaf4ea02960d50d8345f3e174c698af21ad1c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52125
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
For most system calls, it doesn't matter if the PC is advanced to the
instruction after the system call instruction before or after the system
call itself is invoked, because the system call itself doesn't interact
with it.
For some system calls however, specifically "clone" and "execve",
advancing the PC *after* the system call complicates things, because it
means the system call needs to set the PC to something that will equal
the desired value only *after* it's advanced.
By setting the PC *before* the system call, the system call can set the
PC to whatever it needs to. This means the new cloned context doesn't
need to advance the PC because it's already advanced, and execve doesn't
need to set NPC, it can leave the PC set to the correct value from the
entry point set during Process initialization.
Change-Id: I830607c2e9adcc22e738178fd3663417512e2e56
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53983
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Kyle Roarty <kyleroarty1716@gmail.com>
Remove the line "For use for simulation and test purposes only" in files
were AMD is the only copyright holder listed in the header. This happens
to be the case for all files where this line exists, removing it
completely from gem5.
Change-Id: I623f266b002f564301b28774f49081099cfc60fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53943
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 CustomResource can be used to specify a custom, local disk image.
It allows the user to specify the disk root partition parameter
considerably easier than when setting a disk image through a
CustomResource.
Change-Id: I8189ad065124d028aea9fab1c7f07108aa4ce6d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53844
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
CustomResource's base class, AbstractResource, must be constructed with
a dictionary for the 'metadata' field. However, if the user did not
specify any metadata for the CustomResource, None is passed. This is
not permitted and can cause error. This patch ensures the metadata is
set to an empty dictionary by default
Change-Id: I358725ee6982dc9c6410eac3ad8194fa676dd326
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53843
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like gem5py which uses the same main source file, this program will run
arbitrary python scripts. Unlike the other program, it will include
support for the m5 module. That will make it capable of generating
SimObject param, enum, etc c++ files.
Change-Id: I15fd7545f6b1ea6559cbe27cef30c778867ebe70
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I can't conclusively verify that this issue has been fixed because I
can't find any information about it on the internet. It's "SCons bug
2006" and "gem5 bug 308" but neither project still uses whatever bug
tracking mechanism those numbers correspond to. The change was mentioned
in the gem5 code base at least as early as 2008, and so hopefully has
been fixed in the last 13 years. I did a clean build without this
workaround, and things seem to work.
Change-Id: I155f0e72cb720fb5d35d8098375a45a69ea02263
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49419
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By separating out this utility class, we make it possible to build
embedded python modules into other binarys without dragging along lots
of other, unrelated gem5 dependencies.
Also, move the class from sim/init.hh (which is a largely unrelated
name) to python/embedded.hh which much more directly describes what that
file contains.
Change-Id: Ia83439144893ad8401a5d51003e2686d9c9b2d7b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49418
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Put that code into a singleton class in src/proto, so that it gets
called during initialization and teardown of gem5 without cluttering up
gem5Main. This also removes the need to use #ifdefs to guard for
actualling having protobuf support.
Change-Id: I93b5d994eee478a9c159a3f3d02b3e996af02a3e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49416
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Use pybind11 to avoid having to use the python C API directly, which is
simpler, easier to read, and less error prone. Also, use its
PYBIND11_EMBEDDED_MODULE macro to set up the _m5 module instead of a
callback which has to be proactively called from main().
Change-Id: I9c8bcebea934844d16a1fdd88f66a5e66ef0486f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49413
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
m5MainCommands had been a way to override the python code which would
get the python side of gem5 started, used by some "unit" tests which
were really tests of all of gem5 but focus on a particular area. Those
tests have either been converted into real unit tests or eliminated,
and so that mechanism is no longer needed.
This change eliminates that mechanism, and also uses pybind11 to
significantly simplify the code that calls m5.main().
Change-Id: I553ae17074cd5389708f1b7313630a13a6946d76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49412
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, the importer module was built into gem5 as a compressed
bytecode blob like all the other code, and it had to be singled out and
installed manually so that it could help bring in all the other modules.
That adds some amount of complexity since it has to be identified and
treated as a special case.
Instead, this change builds it into gem5 using pybind11's
PYBIND11_EMBEDDED_MODULE macro, and a string that gets evaluated into
the new module's __dict__. This means the importer module is
automatically available just by building in that .cc, and it can just be
imported to start using it.
Theoretically all the embedded python could be handled this way, but
that would mean building it into gem5 as raw strings which wouldn't even
be compiled into byte code until run time. That would take more space in
the binary, and also delay catching simple errors.
Change-Id: Ic600bf6bce41a53289a2833484a655dd5a226e03
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49410
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
