The main change is to remove vector registers from the GDB stub.
Those registers were intended for SVE, which is a new architecture feature
and not yet treated by default on the GDB present in Ubuntu 18.04, and
possibly not even on GDB master.
As a result, aarch64 GDB stub connections would fail with:
Remote 'g' packet reply is too long
The correct way to support those registers is to send XML GDB target
description files to the client. This feature is not yet available for
any architecture, and should be implemented in future patches.
Other smaller fixes are:
* cpsr is uint32_t in aarch64 as well as arm
* use M5_ATTR_PACKED on the register structs since they are being cast and
sent as byte arrays
Change-Id: I77cd8a98e322ecc60799e5b11fe5cd414d893cc7
Reviewed-on: https://gem5-review.googlesource.com/c/14495
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
The value that is not initialized has a bogus value that manifests when
using some debug-flags what makes the usage of tracediff a bit more
challenging.
In addition, while debugging with other techniques, it introduces the
problem of understanding if the value of a field is 'intended' or just
an effect of the lack of initialisation.
Change-Id: Ied88caa77479c6f1d5166d80d1a1a057503cb106
Signed-off-by: Giacomo Gabrielli <giacomo.gabrielli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13125
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The Bitselect operation definition used ~ to invert the bits of a mask
value, but if that mask value is of type bool, that generates a
warning. This change casts that value to a uint64_t so that it can
always have ~ applied to it.
Change-Id: I7fbfc6ff264bc32a265f2724c772b8fae08590f7
Reviewed-on: https://gem5-review.googlesource.com/c/14655
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Neither assert(0) nor assert(false) give any hint as to why control
getting to them is bad, and their more descriptive versions,
assert(0 && "description") and assert(false && "description"), jury
rig assert to add an error message when the utility function panic()
already does that directly with better formatting options.
This change replaces that flavor of call to assert with panic, except
in the actual code which processes the formatting that panic uses (to
avoid infinitely recurring error handling), and in some *.sm files
since I don't know what rules those have to follow and don't want to
accidentaly break them.
Change-Id: I8addfbfaf77eaed94ec8191f2ae4efb477cefdd0
Reviewed-on: https://gem5-review.googlesource.com/c/14636
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The implementation of the getdents syscall relies on SYS_getdents, which
is not available on all archs, because the getdents syscall has been
superseded by getdents64, and does not exist on newer archs such as
aarch64.
This leads the build to break on aarch64 hosts with error:
error: 'SYS_getdents' was not declared in this scope
Change-Id: I8701fb5b61c0418b14a9463ef135a391a7f7a9ba
Reviewed-on: https://gem5-review.googlesource.com/c/14596
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
This DPRINTF shouldn't be necessary since it shows the operands and
results of the instruction which the trace should already make
available. Also by passing the destination register to DPRINTF, the ISA
parser will assume that it's also a source when tracking dependencies.
Change-Id: I820387c82578bdbb8d2e3d91652a6c0185077f54
Reviewed-on: https://gem5-review.googlesource.com/c/14475
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
This patch is implicitly deprecating the usage of bootloader patching,
which is injecting instructions from gem5 into the bootloader
binary. This was probably meant to provide a dynamic bootloader
entry point.
This is not needed in ARMv8.0, since we can simply update the
ArmSystem::resetAddress with the bootloader entry point.
Change-Id: I0c469873b8d69f7b49a7383e0754468bc1f2bd72
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/14001
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
ARMv8 differs from ARMv7 with the presence of RVBAR register, which
contains the implementation defined reset address when EL3 is not
implemented.
The entry 0x0 in the AArch32 vector table, once used for the Reset
Vector, is now marked as "Not used", stating that it is now IMPLEMENTATION
DEFINED. An implementation might still use this vector table entry to
hold the Reset vector, but having a Reset address != than the general
vector table (for any other exception) is allowed.
At the moment any Reset exception is still using 0 as a vector table
base address. This patch is extending the ArmSystem::resetAddr64 to
ArmSystem::resetAddr so that it can be used for initializing
MVBAR/RVBAR. In order to do so, we are providing a specialized behavior
for the Reset exception when evaluating the vector base address.
Change-Id: I051a730dc089e194db3b107bbed19251c661f87e
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/14000
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
RVBAR has been added to the system register list since ARMv8.0-A. It is
implemented only if the highest Exception Level is different (minor)
than EL3. If that's not the case, MVBAR is used. Since the two
registers are mutually exclusive (depending on the presence of EL3),
they share the same coprocessor numbers:
p15, 0, c12, c0, 1
Rather than introducing a new register alias, we overload MVBAR so that
it is treated as RVBAR if ArmSystem::highestEL() < EL3. This patch is
changing the MiscReg info so that EL1 or EL2 access MVBAR (as RVBAR).
N.B MVBAR is RW, whereas RVBAR is RO
Change-Id: Ida3070413fd151ce79c446e99a2a389298d5f5bd
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/13999
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Having an enum number might be useful in case we wanted to know how many
miscregs we have, but on the other hand it makes it tedious to update
the register list, since every commented number must be bumped. This
patch is removing the comments holding the MISCREG numbers
Change-Id: Ic5aba93885e4b8d6cb3bd6a4c49900b9e5474276
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/13996
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This makes them more consistent with the other architectures, helping
to facilitate having a single, unified type across ISAs in the future.
Change-Id: I65efb10e39d453281b8429eeedbb46fa6b023a2b
Reviewed-on: https://gem5-review.googlesource.com/c/13620
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
For operands which default to uw (uint32_t), there's no reason to
explicitly specify that all over the place. Also, when assigning to a
32 bit value which is supposed to be the full width of the resulting
register, there's no reason to override the value to be signed. If the
value is expanded into a larger value, then extra bits may get set
unintentionally through sign extension. Even if an instruction
produces a value which should be interpreted as signed, it will still
only produce a value of a certain predefined width, even if that answer
ends up stored in a larger variable.
Change-Id: I048d68c5dd08a1d40e8117ae9d36d70e05ec21c8
Reviewed-on: https://gem5-review.googlesource.com/c/13618
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
The IntReg type is 32 bits, and using it to cast the syscall return
value is appropriate, but we're attempting to get rid of the ISA
specific register types.
Change-Id: I42496dd2cc086a6b718e1ce087fef81bb897d02f
Reviewed-on: https://gem5-review.googlesource.com/c/13619
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The NULL ISA doesn't actually have registers, so this setting doesn't
matter. By making it 64 bits the ISA is more compatible with the other
ISAs.
Change-Id: I2c9b6d9a6f612719b8b00eb9dbed55fa2159e9b5
Reviewed-on: https://gem5-review.googlesource.com/c/13617
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
These types aren't used by the ISA itself since they're defined to be
particular primitive types in the ISA description. This just affects
code outside of the ISA which work with those types of registers.
Change-Id: I4f62ab8fe04184cc23845090c82b250145a71747
Reviewed-on: https://gem5-review.googlesource.com/c/13616
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
When a s2Lookup object is created, a new request is created, based
upon the original, stage 1 request sent out by the CPU. When a fault
occurs during the second stage of translation, this new request is
returned. This can lead to issues with the O3 CPU. The O3 fetch stage
will not acknowledge the fault as it is a different request than the
one it sent out and does not contain a contextID. This commit
rectifies this.
Change-Id: I21cb7377a59aed9d90d99f048b2106eaf219e93a
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13782
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Some address translation instructions will stop translation after
the 1st stage and intercept the IPA, even in the presence of
stage 2 (eg AT S1E1). However, in the case of a TLB miss, the
table descriptors still need to be translated from IPA to PA to
avoid fetching the wrong addresses. This commit splits whether
IPA->PA translation is required for the VA and/or for the table
descriptors.
Change-Id: Ie53cdc00585f116150256f1d833460931b3bfb7d
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13781
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This is especially important because the Ubuntu 18.04 packaged
arm-linux-gnueabihf-gcc uses the system call on the program initialization,
which leads all programs to fail with:
fatal: syscall openat (#322) unimplemented.
Change-Id: I5596162ad19644df7b6d21f2a46acc07030001ae
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13004
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
While there is a AArch32 class for instructions accessing implementation
defined registers, we are lacking for the AArch64 counterpart.
we were relying on FailUnimplemented, which is untrappable at EL2 (except
for HCR_EL2.TGE) since it is just raising Undefined Instruction.
Change-Id: I923cb914658ca958af031612cf005159707b0b4f
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/13779
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This patch refactors AArch64 MSR/MRS trapping, by moving the trapping
helpers in arch/arm/utility and in the isa code into a MiscRegOp64
class.
This class is the Base class for a generic AArch64 instruction which is
making use of system registers (MiscReg), like MSR,MRS,SYS. The common
denominator or those instruction is the chance that the system register
access is trapped to an upper Exception level. MiscRegOp64 is providing
that feature.
What do we gain? Other "pseudo" instructions, like access to
implementation defined registers can inherit from this class to make use
of the trapping functionalities even if there is no data movement
between GPRs and system register.
Change-Id: I0924354db100de04f1079a1ab43d4fd32039e08d
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/13778
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
According to the arm arm, CPTR_EL3.TCPAC traps EL2 accesses to the
CPTR_EL2 or HCPTR, and EL2 and EL1 accesses to the CPACR_EL1 or CPACR,
are trapped to EL3, unless they are trapped by CPTR_EL2.TCPAC.
Change-Id: I637be35b29db39f044dda0c6cc4fe986c9620371
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/13775
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This fixes:
- unallocated hints that have since been allocated
- unallocated and unimplemented hint instructions being treated as
Unknown instead of the correct NOP
- missing encoding for DBG on A32
Unallocated and unimplemented hints give a warning if executed.
The most important fix was for the CSDB Spectre mitigation
instruction, which was added recently and previously unallocated and
treated as Unknown.
The Linux kernel v4.18 ARMv7 uses CSDB it and boot would
fail with "undefined instruction" since Linux commit
1d4238c56f9816ce0f9c8dbe42d7f2ad81cb6613
Change-Id: I283da3f08a9af4148edc6fb3ca2930cbb97126b8
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13475
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The NULL ISA doesn't really have an endianness. Now that the packet
accessors which consumed that endianness are gone, we can get rid of
that setting as well.
Change-Id: I8dd4c7b8236b07df4458fea377865f30141121d4
Reviewed-on: https://gem5-review.googlesource.com/c/13466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Trying to compile an ARM C hello world with arm-linux-gnueabihf-gcc from
Ubuntu 16.04 leads to a runtime failure with se.py:
FATAL: kernel too old
because the glibc tests if the kernel is at least 3.2.0, and gem5 was
reporting 3.0.0.
Furthermore, it is hard to obtain such toolchain at all: for example
crosstool-NG currently only allows for minimum kernels above 3.2.0.
3.7.0+ was chosen to match the aarch64 value, as it is likely that the
level of support will be very similar.
This commit does not guarantee that full 3.7.0 is supported, but it is
not likely that we had full 3.0.0 support previously either.
However, it is more likely that such support will be eventually achieved
if users can at least try out their programs and implement the missing
system calls as they are found.
Change-Id: I8df3763ae49788a6cb11cb0920e8202cd56b0f09
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/12986
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
This is an old platform, and we haven't had official Linux kernel configs
for it in a while, so we've decided to deprecate it.
Furthermore, trying to use it fails with:
object 'RealViewEB' has no attribute 'pci_host'
and the last commit in the class happened two years ago, which indicates
that no one has been using it.
Change-Id: Icc674b00b152eb3246e05141dbaf2624cc720f21
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/12471
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
