Currently the System class has a mechanism to wait for a GDB connection
for each CPU which has requested it through one of its parameters.
Unfortunately, not every thread context/CPU will be ready for GDB at
that point, particularly considering that in an FS simulation the
kernel won't have been read so there will be no symbols, none of the
registers or the entry point will have been set.
Also in the fast models, the CPUs haven't had a chance to initialize
themselves enough by that point to respond to the API calls which are
used to implement GDB support.
Change-Id: If27cb3e0259a1f67599ab0493695b2f8af640d8e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24963
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Change the guest ABI for x86 pseudo instructions to explictly write rax.
This is required because for some reason, the KVM CPU overwrites rax
after the KVM MMIO sets the value.
Note: This is hacky. It will only work for the current implementations
of x86 m5 ops which have their return value in RAX. A comment is added
to the m5ops file to make this clear.
Change-Id: I9466bf050b26db3650cfe3d23008e0f77fda8bc0
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25664
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
The _on_chip_memory member function is utilised at RealView level, but
it does not provide a default implementation. This assumes all platforms
extending RealView have on-chip memory. This patch provides a default
implementation for safeness.
Change-Id: Iaaa2bee7a85653ee97bfa95b50047eb350a88b58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25643
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
Recent changes in the setupBootloader method didn't take into account
that the VExpress_GEM5_Base class does require "loc" to be passed
to the bootloader setup method:
setupBootLoader(self, cur_sys, loc, boot_loader=None)
However VExpress_GEM5_V2_Base was just passing cur_sys and boot_loader
so that the bootloader was being passed as loc and boot_loader was
passed as None (default parameter):
super(VExpress_GEM5_V2_Base, self).setupBootLoader(
cur_sys, boot_loader)
This patch is fixing this by removing loc from the VExpress_GEM5_Base
interface: the bootloader defaults (usinbg loc) are being set in the
derived classes (V1 and V2)
Change-Id: Ic4d4e4fd8d45a7af9207900287828119c3d7d56c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@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>
With the new ABI API the position argument of the pseudo inst ABI was
not updated correctly. The position needs to be incremented (at least)
once per argument.
Note: `position++` must be outside of the function call because of a GCC
complaint:
build/X86/sim/pseudo_inst.hh:80:48: error: cannot bind non-const lvalue
reference of type 'int&' to an rvalue of type 'PseudoInstABI::Position
{aka int}'
return TheISA::getArgument(tc, position++, sizeof(uint64_t),
false);
Issue: https://gem5.atlassian.net/browse/GEM5-351
Change-Id: Idd890a587a565b8ad819f094147a02dc1519e997
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25543
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@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>
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>
