This code implementes hardware breakpoint exception as part of
software debug explained in ARMv8 reference manual ChapterD2.
+ ArmISA.py: Modify register to allow up to 15 Breakpoint registers
+ Sconscript: Add new file self_debug
+ faults.cc/hh: Defintion and implementation of HardwareBreakpoint
exception inheriting ArmFault.
+ isa.cc/hh: ArmISA contains now an attribute pointing to the SelfDebug
object that will be used to be access SelfDebug infrastructure
Added special cases for setMiscReg to cache debug enable bits.
+ miscregs.hh/cc: Definition and initialization of DBGDCn and DBGDVn
registers.
+ tlb.cc/hh: We include the access to check for breakpoint instruction as
part of the tlb translation process, checking if it comes from a
fetch in the itlb
+ types.hh: Definition of new bitwise register types.
+ utility.cc/hh: Definition and implementation of auxiliar functions for
the selfDebug.
+ self_debug.hh/cc: Main files that include the implemenattion of
breakpoint checks, selfdebug enable and auxiliar functions.
Change-Id: I0e2a4be7f778de560c512253a9148da61e3e7e7a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27967
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, when an instruction has an operand that reads a const
value, it goes thru the same readMiscReg() api call as other
misc registers (real HW registers, not constant values). There
is an issue, however, when casting from the const values (which are
32b) to higher precision values, like 64b.
This change creates a separate, templated function call to the GPU's
ISA state that will return the correct type.
Change-Id: I41965ebeeed20bb70e919fce5ad94d957b3af802
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29927
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This fixes conditions that perform a redundant check to
see if an unsigned value is greater than or equal to
zero. With gcc 10.x, this generates the following error
because of implicit usage of the "-Werror=type-limits"
flag.
"comparison of unsigned expression in '>= 0' is always true"
Change-Id: Ib1a88035ef5fba410d18de0adf614db4bc634faf
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30474
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 patch sets the faulting flag in atomic, timing, minor and o3 CPU
models.
It also fixes the minor/timing CPU models which were not respecting the
ExecFaulting flag. This is now checked before calling dump() on the
tracing object, to bring it in line with the other CPU models.
Change-Id: I9c7b64cc5605596eb7fcf25fdecaeac5c4b5e3d7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30135
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 patch adds a faulting flag to InstRecord.
This allows tracers to identify that the traced instruction has
faulted, when ExecFaulting is enabled. It can be set with
InstRecord::setFaulting() and read with Instrecord::getFaulting().
Change-Id: I390392d59de930533eab101e96dc4d3c76500748
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30134
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We already provide to the user the CCFLAGS_EXTRA, LDFLAGS_EXTRA
variables to pass flags to scons when compiling/linking gem5.
Those variables are not passed to the marshal object.
We add an extra pair:
MARSHAL_CCFLAGS_EXTRA, MARSHAL_LDFLAGS_EXTRA
to add flag injection capabilities to the marshal object.
The patch is also renaming base_py_env to marshal_env.
This happens for 2 reasons:
1) At the moment the marshal compilation is the only task
making use of the base python environment.
2) Consistency with the EXTRA variable names added with this patch.
I could have named them as BASE_XXFLAGS_EXTRA, but it seems too much
generic and users might be confused by that, as they might think
the BASE_XXFLAGS_EXTRA is a subset of the XXFLAGS_EXTRA so that
setting it will affect gem5 compilation as well.
Change-Id: I3e420caa897059455ff8f35462db2b38da050e93
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30016
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Instructions that use the SDWA field need to use the extra SRC0
register associated with the SDWA instruction instead of the
"default" SRC0 register, since the default SRC0 register contains
the SDWA information when SDWA is being used. This commit fixes
15de044c to take this into account. Additionally, this commit
removes reads of the registers from the SDWA helper functions,
since they overwrite any changes made to the destination register.
Finally, this change modifies the instructions that use SDWA to
simplify the flow through the execute() functions.
Change-Id: I3bad83133808dfffc6a4c40bbd49c3d76599e669
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29922
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, with HSAIL, we were guaranteed by the HSA specification
that the GPU will never issue unaligned accesses. However, now
that we are directly running GCN this is no longer true.
Accordingly, this commit adds support for unaligned accesses.
Moreover, to reduce the replication of nearly identical
code for the different request types, I also added new helper
functions that are called by all the different memory request
producing instruction types in op_encodings.hh.
Adding support for unaligned instructions requires changing
the statusBitVector used to track the status of the memory
requests for each lane from a bit per lane to an int per lane.
This is necessary because an unaligned access may span multiple
cache lines. In the worst case, each lane may span multiple
cache lines. There are corresponding changes in the files that
use the statusBitVector.
Change-Id: I319bf2f0f644083e98ca546d2bfe68cf87a5f967
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29920
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Kernel end release was turned on for VIPER protocol, which
is in fact write-through based and thus no need to have
release operation. This changeset splits the option
'impl_kern_boundary_sync' into 'impl_kern_launch_acq'
and 'impl_kern_end_rel', and turns off release on VIPER.
Change-Id: I5490019b6765a25bd801cc78fb7445b90eb02a3d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/29917
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Xianwei Zhang <xianwei.zhang@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Initialize _stackSize and _stackMin to the maximum stack size values.
The are setup in each arch's Process::initState and may be uninitialized
until then. If a stack fixup occurs before these are setup, addresses
which are not in the stack might be allocated on the stack. This
prevents that until they are initialized in Process::initState. If an
access occurs before that with these initial values, the stack fixup
will simply allocate a page of memory in the stack space. However, it
will not print the typical info messages about growing the stack during
this time.
Change-Id: I9f9316734f4bf1f773fc538922e83b867731c684
JIRA: https://gem5.atlassian.net/browse/GEM5-629
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30394
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>
Certain micro-op sequences were only setting isLastMicroop flags,
and did not set the isFirstMicroop flag. This adds the missing
setFirstMicroop() calls. This fixes tracing issues (e.g. Tarmac)
of certain micro-opped instruction sequences such as LD1.
Change-Id: I7de3ee2759e2b4e1065a7cbac4186f11227d84be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30034
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These defaults are never used. There was an assert in the predictors
until recently which was asserting that one of the arguments didn't
have the default value, I think to verify that the default wasn't used
by accident(?), but it could be used purposefully. That would cause
gem5 to crash and has been removed.
Beyond that, there's no reason to have default values for those
arguments in the first place, so this change removes them. That makes
the code slightly simpler, and avoids them being used by accident.
Additionally, the defalt values of the arguments made the function
signatures inconsistent, even though they were supposed to override
each other.
JIRA: https://gem5.atlassian.net/browse/GEM5-483
Change-Id: I28f8d2048985c12ec9cac018a868a32bfa20dc6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30375
Reviewed-by: Hsuan Hsu <hsuan.hsu@mediatek.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
These are the stats in the base class, not in any derived classes. Only
Alpha has an additional stats. These were not really "kernel"
statistics, they were just applicable primarily in FS. They are
potentially applicable to any simulation, but will probably not be
incremented in SE simulations.
Also this merges these stats from being per thread to being per
workload, ie operating system instance. This is probably more relevant
since exactly what thread within a workload runs which particular
instruction is not very important/predictable, but the aggregate
behavior is. If necessary, this could be adjusted in the future to
split things back out again into stats per thread while keeping them
inside the single workload object.
Change-Id: I130e11a9022bdfcadcfb02c7995871503114cd53
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25147
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
