Those lines are sensitive to the paths to the test files and are even
redacted in the golden reference output, presumably for that reason.
Change-Id: I9fbd94c1b6d9d4e76397e84a4175d326f27b6e4d
Reviewed-on: https://gem5-review.googlesource.com/c/12451
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Those messages include an error number in the Accellera implementation.
Add those numbers to gem5 so it's easier to check against golden
reference output for the regression tests.
Change-Id: I35054dd187e86a87eb177f4695d61044c58ce262
Reviewed-on: https://gem5-review.googlesource.com/c/12450
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Some of the details of these messages would be annoying to match
exactly, and the error messages in gem5 go to simerr which isn't
being checked.
Change-Id: If80b124dd99987e205ccaf81d313d35df4191252
Reviewed-on: https://gem5-review.googlesource.com/c/12449
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Those mechanisms for creating processes are only allowed before the
end of elaboration, or in other words before sc_start is called.
Technically the check in Accellera's implementation won't trigger if
the simulation is stopped, and we immitate that behavior.
Change-Id: I9b8b5bd32f876781b6e0d5c0ee0e09de19bdabc1
Reviewed-on: https://gem5-review.googlesource.com/c/12447
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Some tests expect to fail. For those tests (and only those tests) we
need to tell verify.py that it's ok if their exit status isn't 0. Also
if those tests *don't* fail, then that will also be flagged as an
error.
This is done by adding an expected_returncode file into the test's
source directory which holds what the expected return code should be.
Change-Id: I239a28e1d98dd3f76b71028660e492f675a0b3cb
Reviewed-on: https://gem5-review.googlesource.com/c/12446
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If a thread self suspends, it should be marked as ready after resuming.
If a process was already ready when suspended, it should also be
remarked as ready after resuming.
Special care has to be taken in pre-initialization situations so that
processes are put on the right lists, and whether a process is tracked
is already marked as ready.
Change-Id: I15da7d747db591785358d47781297468c5f9fd09
Reviewed-on: https://gem5-review.googlesource.com/c/12445
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
When a process is sensitive to an event finder and that finder is
attached to a port which is bound to multiple interfaces, the process
is supposed to be made sensitive to the event finder function's result
when called on each interface, not just the first one.
Change-Id: I92312e04e60fab7a7ea51c1ed687edabe9768205
Reviewed-on: https://gem5-review.googlesource.com/c/12444
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Processes which are created in end_of_elaboration aren't created with
sc_spawn but still need to figure out if they're dynamic. Rather than
duplicate the check in sc_spawn, this change centralizes it in the
Process class itself.
Change-Id: I763d5a0fa89a72fbc82346b6ce2eed852ee72524
Reviewed-on: https://gem5-review.googlesource.com/c/12443
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If systemc attempts to schedule an event in the past, schedule it for
right now instead. Still preserve the difference between delta and
timed events. This scheme doesn't really make a lot of sense (why not
just disallow scheduling events in the past?) but this will approximate
what I think the correct behavior is. What's probably supposed to
happen is that events in the past are executed from most past to most
present until they catch up with now, and then now advances as normal.
Our approach is simpler, but won't preserve ordering between multiple
events scheduled in the past.
Change-Id: I73c1e581c532530178458f044674613a4f4ea3be
Reviewed-on: https://gem5-review.googlesource.com/c/12277
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
AArch32 and AArch64 have different HWCAP flags in Linux, but we are
currently using AArch32 HWCAP flags to initialize the aux vector of both
AArch32 and AArch64 binaries.
This patch also fixes a bug that was introduced by running in SE mode a
target binary compiled with glibc > 2.18. Using AArch32 flags
resulted on CPUID flag being set for AArch64. This incorrectly tells
libc that emulation of the midr_el1 is supported.
In FullSystem this might work, but since we are in Syscall Emulation
there is no OS behind emulating the mrs midr_el1 instruction.
By separating AArch32 flags from AArch64 flags we are turning off the
CPUID hwcap flag in SE mode.
Change-Id: I9f651957ba9d19dc2bc06606de070c6586f0f9fa
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/12884
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
This changeset:
- extends fplib to support emulation of half-precision floating-point
(FP16) operations;
- extends fplib to support additional primitives introduced by the Arm
Scalable Vector Extension (SVE) (fplibExpa, fplibScale,
fplibTrigMAdd, fplibTrigSMul, fplibTrigSSel);
- adds the FZ16 bit to FPSCR;
- cleans up fplib code by replacing constants with preprocessor macros
and by adding inline functions to recognise NaNs and infinities.
Change-Id: If8fdb2a5824b478c8310bbc126ec60cc1105f135
Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/13044
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This patch is implementing the following AArch64 ID registers as
bitunions, so that it is easier to query for feature availability:
- ID_AA64DFR0_EL1
- ID_AA64ISAR0_EL1
- ID_AA64ISAR1_EL1
- ID_AA64MMFR1_EL1
- ID_AA64MMFR2_EL1
- ID_AA64PFR0_EL1
They are updated to the latest Armv8.5 arch release version.
RES0 only ID registers like ID_AA64AFR1_EL1 haven't been added.
Change-Id: Ied037abe3757421bcfc2834d397a8cf9a2b9f0a7
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/13067
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
As the number of MiscRegs increases there is the need of a cleaner
header file; this patch is separating miscreg.[cc,hh] where the miscreg
decoding/utility functions are defined/declared from the MiscReg
register types (BitUnion).
Change-Id: I815f53b117b50e47f93aa13d78356ef09d2a2541
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/13065
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
One of the auxv vector's flag is the HWCAP, whose bits match the content
of several arm ID registers. This patch factors out AArch64 ID
registers init into a separate method and creates the symmetric AArch32
ID register init as well, so that we get a meaningful auxiliary vector
in SE mode.
Change-Id: I52bdb31b67508c4447558ebd7ca743733a69280e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/13064
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Read/WriteCpu methods in the GICv2 are accessing the GICC_CTRL register
as if writing any non-zero value to the register will enable IRQ
signaling to the CPU. Instead, only the 2 least significant bits
control group0/group1 enablement. This patch is renaming GICC_CTRL
underlying data buffer from cpuEnabled to cpuControl and it is making it
an array of uint32_t instead of bool. cpuEnabled now becomes a method
and checks if GICC_CTRL.EnableGrp0 or GICC_CTRL.EnableGrp0 are set.
Change-Id: I40f0b3c52c40abd482a856f032bf3686f96ef641
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12945
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Writing a 1 to the Overflow Flag Status register should trigger an
interrupt raise/clear depending on the register we are currently using
(PMOVSCLR for clearing and PMOVSSET for raising).
Change-Id: I2091456685a245712045cf7a4932ac36b7dded1d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12531
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
644e8cdf5e ("util: Move the m5ops.h file to a shared directory")
added include/ to the include path for m5 Makefiles, based on
$(PWD): $(PWD)/../../include.
Unfortunately, this breaks when using `make -C <path>`, as -C does
not move PWD accordingly. The fix is simply to remove $(PWD), as a
relative path is just fine here.
Change-Id: Ia046c29761363b6670e52c52a604c7e70a6a305a
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Signed-off-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/12844
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The tests expect to be run from a certain directory. Generally that
doesn't matter, but in at least one case the test opens a file with a
relative path, and that doesn't work unless CWD is what it expects.
Change-Id: I34c0ed975e77daed50ace4f7eebd034bf04c5595
Reviewed-on: https://gem5-review.googlesource.com/12271
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Use rpath to link the gem5 dynamic library into the systemc test
binaries so that they don't have to be run from a particular directory
to resolve all their linking dependencies.
Change-Id: I66b18c23ae6bbf32a959022f8789fc8bdd3a6c6b
Reviewed-on: https://gem5-review.googlesource.com/12270
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
When in sc_main, sc_is_running will return true but we're not going
to run any gem5 events since we're currently in the sc_main Fiber. In
that case, we need to do the sc_stop work inline.
If we're actually running and not just paused, then we do still want to
schedule the work of sc_stop to happen as its own event since that will
happen before returning to sc_main, and actually will likely be the
mechanism by which sc_main starts executing again.
Change-Id: If9ffafc4f240af0f3d9c726b36a0950b5219dc00
Reviewed-on: https://gem5-review.googlesource.com/12269
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make sure we check for starvation after timed notifications and at the
very end of delta cycles (after delta notifications, not before). Also
reverse the order of starvation checks (whether they apply at all, then
if they're satisfied) to make those checks faster. Checking a bool
is a lot easier than checking if a bunch of other structures are
empty.
Change-Id: I514ff219909823f1f424fde69856d6b510655188
Reviewed-on: https://gem5-review.googlesource.com/12268
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The ready event is what notices that we only wanted to run one delta
cycle, or no delta cycle if there was nothing to do, and return to
sc_main. If the ready event wasn't scheduled, we would advance time
before the ready event ran and returned to sc_main which is incorrect.
Change-Id: Ic3c10a2f1405f744e8c2bd37aa45846ee6e98e12
Reviewed-on: https://gem5-review.googlesource.com/12267
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If sc_stop is called during one of the various callbacks, that has
defined behavior and will cause the simulation to stop after the
current batch of callbacks. We were checking whether sc_stop had been
called during one of those batches and killing the system, erroneously
assuming that meant it had called during elaboration.
This change moves the check to before the callbacks which actually
does mean that sc_stop was called during elaboration.
Change-Id: I6876305450e52a407acffb9a2f45ee2ae24a9adf
Reviewed-on: https://gem5-review.googlesource.com/12266
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Methods may need to yield control to other Processes when throwing
them exceptions. In that case, we need to keep track of the fact that
the method doesn't need to be restarted when it resumes within yield.
Change-Id: I829c387d6ddb563b2957db47e55adadbbe6bc51a
Reviewed-on: https://gem5-review.googlesource.com/12265
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Don't just fall off the end of the fiber and return to gem5. By
calling yield, we ensure that remaining Processes are run and that
bookkeeping is maintained correctly.
Change-Id: Ifbe104e155cad29e40a89767a7c1f986399f784d
Reviewed-on: https://gem5-review.googlesource.com/12264
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The sc_port code had been using the .at() function of the vector class,
but when that failed it threw an exception, and it was very difficult
to tell where the exception came from from how gem5 crashed. This
change switches to sc_assert (the systemc version of assert) which
makes the cause/location of failures much more obvious.
Change-Id: I1cd51c86f47b314be551c304b014c44cfa030175
Reviewed-on: https://gem5-review.googlesource.com/12262
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
