This will let a function called with a GuestABI emulate the ...
mechanism available in C. To make that possible without the functions
knowing anything about the ABI and to follow C++'s (sensible)
templating and virtual function rules, you have to tell VarArgs what
types you might want to extract from it, unlike the pure ... varargs
style mechanism.
Also unlike ..., there is no mechanism in place to force the varargs
to appear last in the argument list. It will pick up the progress
through the arguments at the point it's reached, and will ignore any
later arguments. It would be possible to be more rigorous about this
by changing the callFrom templates, but the overhead in complexity
is probably not worth it.
Also, retrieving arguments through a VarArgs happens live, meaning at
the point that the argument is asked for. If the ThreadContext or
memory the argument lives in is modified before that point, the
retrieved value will reflect that modification and not what the
function was originally called with. Care should be taken so that this
doesn't cause corrupted arguments.
Finally, this mechansim (and the Guest ABI mechanism in general) is
complex and should have tests written for it. That should be possible
since ThreadContext is forward declared and so the test can say it
works however it wants or even ignore it completely. If that changes
in the future, we may need a mock ThreadContext implementation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I37484b50a3e8c0d259d9590e32fecbb5f76670c1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23195
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The default constructor of the micropc enabled generic PCState class
set the next micropc to 0, when the non-default constructor and at
least the x86 initCPU utility function set it to 1. This makes more
sense since either the micropc doesn't matter as a concept if the
instruction isn't microcoded, or, unless redirected by a micropc
branch, you're going to want to execute the next microop and not just
repeat the first one.
Change-Id: I418ea986a071453563c4c8aad4fc4eb4f7beb641
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24184
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
VExpress_GEM5_Base states that its memory map is based on
CoreTile Express A15x2 A7x3, while the model used for the
Daughterboard Configuration Controller (DCC) is based on
Coretile Express A15x2.
These two daughterboard specifications differ in both on-chip
memory map and DCC clocks as of the TRMs.
This patch makes the reference consistent to Coretile Express
A15x2 and adds several non-confidential references to aid in
understanding the platform and adding new peripherals.
Change-Id: Ia55e7362bdc9ed6509f8eff4cbd7eb38e538d774
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24203
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously the `GTestExitLogger.log` function utilized GTest's
`ADD_FAILURE_AT` macro. This meant, whenever `GTestExitLogger.log` were
called, the calling test would be fail. This is problematic when
trying to test code we expect to fail (i.e., when testing the error
handling code is working correctly). Therefore, the `log` function now
writes to stderr.
The `GTestExitLogger` class is used by the `panic` and `fatal` loggers
when running GTests. Instead of callnig `exit(1)` they throw a GTest
exception, which can be captured in a test using
`EXPECT_ANY_THROW(expection_thrower())`. Catching and verifying error
logs can be done via:
```
testing::internal::CaptureStderr();
/*
* "exception_thrower()" is a method we'd expect to call `fatal` or
* `panic`, and therefore exit the simulation with a non-zero exit
* code. When running via GTest, an exception is thrown instead.
*/
EXPECT_ANY_THROW(exception_thrower());
EXPECT_EQ("<error message>", testing::internal::GetCapturedStderr()));
```
Change-Id: I84a5f86bc573668d3dd5b40f626b43108dddb8e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23983
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
amo.hh was using several non-default definitions including
std::function, uint8_t, and std::array without including any headers
at all, and instead apparently relying on those having already been
brought in by an earlier include.
This change adds those includes explicitly.
Change-Id: I92166ff581e74bd705e10fd4fa454df179ae1a97
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24183
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, when `tests/main.py run` was executed all the tests found
were run. It is now necessary to ignore some test suites as they fail.
Therefore, `gem5/suite.py` has been updated to read from `gem5/.testignore`
(if present). This file contains a list of all the test suites which are to
be ignored.
Change-Id: I699ea662b701d82199980084261496f24b13d340
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23023
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This mechanism is shared between ARM and x86, even if x86 has a typical
address range it choses to use. By moving this to the base class, it's
now possible for anybody to find out where the m5 ops are, and no ISA
specific assumptions need to be made.
Because the x86 address is well known, it's set in the x86 System
subclass as the default.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Ifdb9f5cd1ce38b3c4dafa7566c50f245f14cf790
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23180
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the MSHR is handling a request that will make the block dirty the
current cache commits respond. When that's not the case the cache
should forward any snoops. This CL fixes MSHR::handleSnoop() to
implement this behavior.
Change-Id: I207e3ca4968fd9528fd4cdbfb3eb95f470b4744d
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23668
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
The original implementation doesn't set trans and phase correctly when
scheduling PayloadEvent, and causes unexpected behavior after the event started.
This change fixes the wrong event triggering by directly applying
tlm_utils::peq instead of creating another one.
Change-Id: I207567b57f4b49c3c4ebe117d624e5cc9915c12a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23823
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Right now, there are only two places which call the pseudoInst function
directly, the ARM KVM CPU and the generic mmapped IPR. These two
callers currently use the generic "PseudoInstABI" which is just a
wrapper around the existing getArgument function.
In the future, this getArgument function will be disolved, and the
PseudoInstABI will be defined for each ABI. Since it currently mimics
the Linux ABI since gem5 can only handle one ABI at a time right now,
this implementation will probably be shared by linux system calls,
except that the pseudo inst implementation will eat return values since
those are returned through other means when the pseudo inst is based on
magic address ranges.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Ied97e4a968795158873e492289a1058c8e4e411b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23178
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code block was relying on passed_predicate only (conditional
execution). This was not covering the case where the instruction
gets executed, but the predicate register is false. Using the inLSQ
variable is covering both cases and it makes more sense in terms of
readibility.
Change-Id: Ie1954f37968379a5bda9d0dc9f824a68304cc229
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23280
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changes fixes two compilation errors when compiling with
FastModels. One is that CurrentMsn should be Iris::CurrentMsn and the
other is that currEL() function needs arch/arm/utility.hh header file.
Test by compiling GEM5 with FastModels:
scons -j64 build/ARM/gem5.opt \
USE_ARM_FASTMODEL=1 \
PVLIB_HOME=... \
MAXCORE_HOME=... \
ARMLMD_LICENSE_FILE=... \
Change-Id: Iabe0a5f25246591f99b57219428b8f87ecd3363c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23924
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This specialization will correspond specifically with the CortexA76,
instead of specializing the ThreadContext for ARM in general. Some
aspects of this class may need to move into the base IRIS thread
context class, but I'll leave that for a later change.
Change-Id: I9cbe527d36e6fda78601dc39c1963370cfa28b16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23787
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fast models are in practice only ARM, so it's not that helpful to have
the ARM-ness factored out. It is, however, helpful to have aspects
which control how gem5 concepts like registers are mapped to fast model
concepts like resources, especially since these mappings may vary from
fast model to fast model.
For instance, it looks like the CortexA76 does not have predicate
vector registers. Rather than make all fast models support or not
support those registers, that can be done on a model by model basis.
Change-Id: I195da4a2f4d2f8593032d0d63e9fd3d20a240d01
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23786
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This was hardcoded as 5, but should be determined based on the memory
space IDs the fast model returns. What we do now is have a specific
override for ARM (perhaps conceptually the A76) which looks for an
address space called "Current" which seems to work well.
It's possible that the appropriate address space for a different model
might have a different number, or even a different name. This may need
to be further specialized/parameterized in those cases.
Change-Id: Ie1ef99675fd9bccab50b7fc7add16b82a93bd60b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22143
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These use the IRIS breakpoint API to stop the models at the appropriate
points. There seems to be a slightly wonky interaction between
breakpoints and stepping, where if you stop at a breakpoint and then
step, you might end up moving forward more than the number of requested
instructions.
Change-Id: I31f13a120cfc1ad2ec3669ee8befd6d21b328bb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22122
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
At the moment is impossible when observing an upstream kokoro failure
to understand what went wrong.
This is because the only thing that gets printed is the exception
traceback and the command line generating it.
Most of the time it will be something like
Traceback (most recent call last):
File
"/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/runner.py", line
195, in setup
fixture.setup(testitem)
File "/tmpfs/src/git/jenkins-gem5-prod/tests/gem5/fixture.py", line
115, in setup
self._setup(testitem)
File "/tmpfs/src/git/jenkins-gem5-prod/tests/gem5/fixture.py", line
160, in _setup
log_call(log.test_log, command)
File
"/tmpfs/src/git/jenkins-gem5-prod/tests/../ext/testlib/helper.py", line
103, in log_call
raise subprocess.CalledProcessError(retval, cmdstr)
With this patch we dump the stderr so that the fail reason is exposed
to the viewer.
Change-Id: Ic3d0fe75ec4d0543d95e9624dc5287afb4af3b8b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23843
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The value of the add and subtract assignment operations can be negative,
and this was not being handled properly previously. Regarding shift
assignment, the standard says it is undefined behaviour if a negative
number is given, so add assertions for these cases.
Change-Id: I2f1e4143c6385caa80fb25f84ca8edb0ca7e62b7
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23664
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is updating the arm regression configs so that the newer
VExpress_GEM_V1 platform is used instead of the older VExpress_EMM and
VExpress_EMM64.
A new optional kernel_mode argument has been added in order to
distinguish between realview and realview64 platforms. If not provided
the config will assume the machine is running a AArch64 kernel.
Other notable additions:
- DTB autogeneration in regressions
- Using minimal m5exit.squashfs disk image
Change-Id: Ia230565f072fe3eb7756c41876dba4657583f4df
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22687
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
