When defining a static constexpr variable in C++11, it is still
required to have a separate definition someplace, something that can
be particularly problematic in template classes. C++17 fixes this
problem by adding inline variables which don't, but in the mean time
having a static constexpr value with no backing store will, if the
compiler decides to not fold away the storage location, cause linking
errors.
This happened to me when trying to build the debug build of ARM just
now.
By turning these expressions into static inline functions, then they
no longer need definitions elsewhere, still fold away to nothing, and
are compliant with C++11 which is currently the standard gem5 expects
to be using.
Change-Id: I647d7cf4a1e8de98251ee9ef116f007e08eac1f3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24964
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
gem5 does not historically distinguish between address spaces when
interacting with gdb, and gdb doesn't really give it any address space
information to work with. To ensure we catch whatever address space
we might be in by the time we get to the interesting address, we'll set
a breakpoint in all possible address spaces simultaneously with the
expectation that we'll hit one of them.
Change-Id: I9f4b93d04914db7a3c42be6236a523d35194afda
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25268
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
When the last event is removed from a breakpoint, then the breakpoint
itself is uninstalled from IRIS, and the list is deleted. Even though
the list has been traversed and so we don't lose track of any other
events that need to be processed, we also still need to check against
end() to see that we're done. If that now freed memory gets
overwritten, then we won't see the end and will wander right off the
end of the list into nonsense.
This change modifies the breakpoint info tracking structure to keep a
shared pointer to the event list. The pointer will still automatically
manage the list's memory so that it doesn't leak, and it won't get
deleted out from under us as we're iterating through it.
Change-Id: I5ad0f095d07f0a3a5cce9c10f03121827a674c33
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24965
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
This only seems to be used from outside of the CPU when resetting state
at the start of execution. Since this state is already reset in
fast model, we can mostly ignore that call for now.
When more accessors are implemented, this function can be use them to
clear registers like it would on other thread contexts.
Change-Id: I5146273387ec17987770abc67f6f426c4480e0b9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24967
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
ArmISA::clear resets the value of the architecture registers. Some of
these are cached in ArmTLB, including SCTLR. This patch invalidates the
cached copies on clear; this fixes a bug when resetting CPU cores by which
the cached SCTLR was used and SCTLR.M was set, resulting in non-arch
compliant reset behaviour and a PA being treated as a VA on translation.
Change-Id: I8d4eeeaf807325bd7b300a7a317abfa40ad23c87
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25466
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Not running the systemc test SConscript reduces the scons startup time
(before any file is compiled) from about 10s to 4s on my machine.
The performance investigation was done at:
https://gem5.atlassian.net/browse/GEM5-256
As before, the systemc tests are still automatically built when
they are run with:
src/systemc/tests/verify.py --update-json build/ARM -j `nproc` \
--filter-file src/systemc/tests/working.filt
Change-Id: I33b7a53c0a7d70386ab17d7bb4886c84a97a2eb3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25385
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I've arbitrarily chosen to make ARM the default ISA for now, since I
think it's the best supported ISA with X86 somewhere a little behind
it. As a compromise, I change all mention of ALPHA (or even ALPHA_SE!)
in comments to be X86 instead, so it gets some attention too.
Change-Id: I1d8edc7925ca2d94f11b26e2c0b9314216e9b97d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25463
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This file doesn't seem to actually get referred to by anything in gem5,
and additionally MIPS FS mode has a ways to go before it can be used.
If this file is really necessary for running MIPS, it can be retrieved
from the history in the future.
Change-Id: I3a86fc928a4be1c9159f0fafb986dfb06d09bb7b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25404
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is achieved by using keyword arguments to improve readibility.
Some of the building helpers are using native types and can be annoying
for a reader to understand what those sequences of number and boolean
mean. It is also easier in this way to commit mistakes.
Change-Id: I63081d09a1f621550c5b6522b8107f349939b21d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24044
Tested-by: kokoro <noreply+kokoro@google.com>
The stdio fgetc returns the character read as an unsigned char cast to
an int.
The reason why it gets casted from unsigned char to int is because EOF
is defined as a negative value (usually -1).
At the moment in the atomicio.test we store the int in a char.
However the C standard states that the sign of a char is implementation
specific. This makes the test non portable: an architecture/ABI which
which is considering a char as a unsigned char won't compile since a
unsigned value will always be != -1 (EOF).
This is the error message you would get on a aarch64 host /w gcc/5.4.0
build/ARM/base/atomicio.test.cc:121:48:
error: comparison is always true due to limited range of data type
[-Werror=type-limits]
Change-Id: I120e44b5204d98e643f19b8dd6fa2762342a6e64
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25384
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
