In SPARC and SE mode, system calls are triggered by a trap exception
with the appropriate trap number, and then a handler within the Workload
(formerly the Process) object recognizes the trap number and triggers
the system call.
For Linux, this special handling happens in the Linux specific Workload,
and other types of traps are passed through to the base SPARC SE
Workload class. For Solaris however, no special handling is implemented.
That means that it's actually impossible for a Solaris SE mode program
to actually trigger a system call, and so while there is some code
written for Solaris SE mode, this feature does not actually work at all.
Also, while it's relatively easy to build binaries for Linux on various
architectures using, for instance, the crosstool-ng configs in util/,
there is no ready made option that I could find for building a SPARC
Solaris cross compiler which would run on x86 linux.
Given that the support that exists isn't actually hooked up properly,
SPARC is not one of the most popular ISAs within gem5, Solaris is not a
widely used operating system, we have (to my knowledge) no test binary
to run, and setting up a cross compiler would be non-trivial, it makes
the most sense to me to remove this support.
Change-Id: I896b5abc4bf337bd4e4c06c49de7111a3b2b784c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33996
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These files are nominally not tied to the X86ISA, but in reality they
are because they reach into the GPU TLB, which is defined unchangeably in
the X86ISA namespaces, and uses data structures within it. Rather than try
to pretend that these structures are generic, we'll instead just use X86ISA
instead of TheISA. If this really does become generic in the future, a
base class with the ISA agnostic essentials defined in it can be used
instead, and the ISA specific TLBs can defined their own derived class
which has whatever else they need. Really the compute unit shouldn't be
communicating with the TLB using sender state since those are supposed
to be little notes for the sender to keep with a transaction, not for
communicating between entities across a port.
Change-Id: Ie6573396f6c77a9a02194f5f4595eefa45d6d66b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34174
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This is still triggered by the generic mechanism that tries out all
paths to go from an object file to a process. That's not entirely
necessary since the only loader that should be used when using the
X86ISA::EmuLinux workload is the one it provides, but the rest of gem5
isn't ready for that change yet.
This removes the last lingering reason to keep around the
arch/x86/linux/process.(hh|cc) files, so they have been deleted.
Change-Id: I425b95c9c730f31291790d63bc842e2c0092960d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33904
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The TLBIALL op in gem5 was designed after the AArch32 TLBIALL instruction.
and was reused by the TLBI ALLEL1, ALLE2, ALLE3 logic.
This is not correct for the following reasons:
- TLBI ALLEx invalidates regardless of the VMID
- TLBI ALLEx (AArch64) is "target regime" oriented, whereas TLBIALL
(AArch32) is "current regime" oriented
TLBIALL has a different behaviour depending on the current exception
level: if issued at EL1 it will invalidate stage1 translations only; if
at EL2, it will invalidate stage2 translations as well.
TLBI ALLEx is more standard; every TLBI ALLE1 will invalidate stage1 and
stage2 translations. This is because the instruction is not executable
from the guest (EL1)
So for TLBIALL the condition for stage2 forwarding will be:
if (!isStage2 && isHyp) {
Whereas for TLBI ALLEx will be:
if (!isStage2 && target_el == EL1) {
Change-Id: I282f2cfaecbfc883e173770e5d2578b41055bb7a
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35241
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add some more stringent Python tests that ensure that we can link with
and run applications that embed Python. This is implemented by running
building a small c++ program that embeds Python using PyBind11. The
program is run by the build system and prints the version of the
Python interpreter. The version information is then used by the build
system to ensure that the installed version is supported.
Change-Id: I727e0832f171362f5506247c022bea365068a0f6
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36383
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The parseParam and showParam functions partially worked using template
specialization, and partially worked using function overloading. The
template specialization could be resolved later once other functions
were added, but the regular function overloads could not. That meant
that it was practically impossible to add new definitions of those two
functions local to the types they worked with.
Also, because C++ does not allow partial specialization of template
functions, it would not be possible to truly use specialization to wire
in BitUnion types.
To fix these problems, these functions have been turned into structs
which wrap static functions. These can be partially specialized as
desired, making them compatible with BitUnions. Also, it's not possible
to overload structures like it is with functions, so only specialization
is considered, not overloading.
While making these changes, these functions (now structs) were also
reworked so that they share implementation more, and are generally
more streamlined.
Given the fact that the previous parseParam and showParam functions
could not actually be expanded beyond serialize.hh, and were not
actually called directly by any code outside of that file, they should
have never been considered part of the API.
Now that these structs actually *can* be specialized outside of this
file, they should be considered part of the interface.
Change-Id: Ic8e677b97fda8378ee1da1f3cf6001e02783fde3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36280
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These had been written specifically for the vector, list, set, and C
style array types. This change reworks them to share an implementation,
and to work with more general types. The arrayParamOut method requires
std::begin() and std::end() to accept that type, and the arrayParamIn
method requires either insert or push_back, or the type to be an array.
Also fix up a couple of files which accidentally depended on includes in
the serialize headers which are no longer necessary.
Change-Id: I6ec4fe3bb900603bbb4e35c4efa620c249942452
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36277
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As gem5 has started to use Python2 incompatible features, compiling
gem5 in a Python2 environment results in an error.
This commit addresses this issue by raising an Exception when scons
is run in a Python2 environment, and adding a few pointers on how to
install Python3 and on how to use scons in a Python3 environment. The
solution works in a system where both Python2 and Python3 are
installed.
JIRA: https://gem5.atlassian.net/browse/GEM5-797
Change-Id: I98d4a39f586f39d9253ab2517b77e86c5ed19466
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36157
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
