This resource has been deprecated in favor of 'x86-ubuntu-18.04-img'. In
practise, these are the same resource (i.e., the same disk image), but
we deprecate 'x86-ubuntu-img' as 'x86-ubuntu-18.04-img' is more explicit
on what the disk image contains. Going forward we may want different
disk image resources with different Ubuntu versions, and we want it to
be clear what the user is retrieving.
Change-Id: I06b08e6b65cf431067ffda35ebd10d419068d073
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54583
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
When checking whether a given option is supported, we try to compile or
link a small test program and see if that succeeded or not. There are
some options which are not really supported, but if you use them the
compiler might produce an error instead of failing to build. An example
of that is clang (version 9 at least) which will warn if you try to
disabled a warning it doesn't know about.
On the develop branch, this is fine since we have werror enabled, and
even these warnings will prevent the options from being enabled. On the
release branches where we disable werror for better future
compatibility, this causes a problem because these options still pass
the test and end up being enabled. This doesn't break the build, but
can cause a bunch of annoying and unnecessary warnings which clutter
up the build output.
To remove this inconsistency, we can enable werror just for the test
compiles or links which decide whether or not an option is supported.
That won't necessarily differentiate *why* a warning was generated, so
if through some strange combination of circumstances something else
causes a warning pervasively through the build, then this may think
an option is to blame and not enable it even though it's fine. This
seems unlikely though, and not worth worrying about without a specific
example showing that it can/will actually happen.
Change-Id: I6a1e3273c0b646a5636dc9986c70dcd5332f6f64
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54624
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
GCN3_X86 and VEGA_X86 can use the same test binaries to run tests for
that build configuration. This adds an option to the nightly and weekly
test scripts to select which GPU ISA to test. By default the GCN3_X86
ISA is tested which was previously the only test. No behavior is changed
from current testing.
Change-Id: Ifedcdea5d7c1c8e9994559a20aea5e1954180772
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54083
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
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>
pybind11 gives us a simple way to set up sys.argv when initializing the
python interpreter, but we need to set that up even if the python
interpreter is already running. We need to do that manually, which we do
like gem5's main() used to.
Change-Id: If9b79a80e05158226d13f68bf06a2a98a36c2602
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54310
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 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>
