The trace mechanism appears to be the only debug flag that does not
go through DPRINTF, presumably for performance reasons.
This patch manually adds that to make things uniform with other debug
flags, e.g. with FmtFlag,ExecAll,SyscallBase a sample output looks like
(truncated to fit into commit message lengths):
0: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue
500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+4
1000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+8
1500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+12
2000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+16
2500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+20
3000: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+24
3500: ExecEnable: system.cpu : A0 T0 : @asm_main_after_prologue+28
Change-Id: Ic371ebc8b0827656f1b78fcfd3f28505a5100274
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22007
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If FmtTicksOff is given, ticks are disabled for all log messages.
The original motivation of this is to bring the implementation of native
traces closer to that of other traces to help refactoring done in future
patches.
One additional advantage of this is that sometimes we want to compare
traces of a given program under different conditions, so the start of the
ROI is different, and the different initial timestamp makes a diff
useless by showing differences on every line.
Change-Id: Idd6cb105d301b3b9b064996043f4ca75ddafe0af
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22006
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes it easier to determine which messages come from which
flags when enabling multiple flags at once.
This commit covers the bulk of the debug messages, which use the DPRINTF*
family of macros. There however macros that use DTRACE to check for
enable, those will be covered in future patches.
Change-Id: I6738b18f08ccfd1e11f2874b426c1827b42e82a2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22004
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The "shamt" in integer shift immediate instructions is an unsigned
immediate encoded in bits[25:20]. While the original Gem5 uses bits[31:20]
as an int64_t. This patch fixes the problem by:
- Adding a new parameter "imm_code" for format IOp and use the correct
bitfields SHAMT5 or SHAMT6 to assign "imm_code" for each instruction.
- Use uint64_t instead of default int64_t to assign parameter "imm_type"
of format IOp.
The instructions affected include:
- Shift Left Logical Immediate, slli
- Shift Right Logical Immediate, srli
- Shift Right Arithmetic Immediate, srai
- Shift Left Logical Word Immediate, slliw
- Shift Right Logical Word Immediate, srliw
- Shift Right Arithmetic Word Immediate, sraiw
Change-Id: Iad34ccd036c11630409f84f6de2b939224e100e6
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22563
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The original Gem5 does not give correct disassembly for instruction fence
and fence.i. This patch fixes the problem by adding two bitfields PRED and
SUCC and a new format FenceOp and a template FenceExecute, in which
operands are generated based on PRED and SUCC in the disassembling
function.
Change-Id: I78dbf125fef86ce40785c498a318ffb1569da46c
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22569
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Software such as Trusted Firmware-A checks the MIDR register
to identify which core model is present in the platform.
The previous default value referred to a Cortex-A15 Armv7-A
processor, however when AArch64 is enabled, an Armv8 processor
is expected.
This patch assigns the Cortex-A57 MIDR if AArch64 is enabled.
Change-Id: Id1677a77d2f04843423f7b013405445f3d253399
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22846
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
At Ia6b4d3e6148c64721d810b8f1fffaa208a394b06 the futex wake up started
skipping selecting threads that are already awake, which already prevented
some deadlocks.
However, threads that are Halting or Halted should not be woken up either,
as those represent cores in which processes have already exited.
Before this commit, this could lead an exited core to wake up, which would
then immediately re-execute the exit syscall, and possibly leave one
genuinely sleeping core locked and:
Exiting @ tick 18446744073709551615 because simulate() limit reached
Change-Id: I1531b56d605d47252dc0620bb3e755b7cf84df97
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22963
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The original Gem5 does not give correct disassembly for atomic
instructions, which are implemented with one or two micro instructions.
The correct register indices are not decoded until subsequent micro
instruction is processed. This patch fixes the problem by getting the
register indices and other properties (aq and rl) from certain bitfields
of the machine code in the disassembling function.
Change-Id: I2cdaf0b3c48ff266f19ca707a5de48c9050b3897
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22568
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
In disassembling compressed instructions, the original Gem5 gives needless
operands, such as register or immediate. This patch fixes the problem.
- Existing formats fixed: CIOp, CJOp, CBOp and Jump.
- New formats added: CIAddi4spnOp (for c.addi4spn only) and CompressedROp (with
templates CBasicDeclare and CBasicExecute)
Change-Id: Ic293836983256a59d3a7aca091c8184b410516a4
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22566
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
For U-type instructions auipc and lui, the 20-bit immediate is left-shifted
by 12 bits in decoding. While the original Gem5 gives the left-shifted
value directly in disassembly.
This patch fixes the problem by
- Assign the original 20-bit immediate to internal variable "imm".
- Output "imm" directly in disassembly, as how the original Gem5 does.
- Do the left-shift to "imm" later in the function defining of each
instruction, rather than in decoding.
Change-Id: I300e26fd9c79478783c39fcd6ff70ea06db88884
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22564
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
When serialize and unserialize an variable, the parameters passed to
SERIALIZE_SCALAR() and UNSERIALIZE_SCALAR() must be the same and should be a
general variable name. If not, the expected item would not be found with
UNSERIALIZE_SCALAR() and a fatal error would be introduced.
This patch fix the bug in class Interrupts of RISCV.
Change-Id: I7dd7ab6805651149304959bdf7ee9f3be9d9eaff
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22643
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
These methods will make reporting errors less verbose and more
consistent, since they'll handle some formating, setting colors,
prefixing with an appropriate "Warning:" or "Error:" tag, and exiting
in the case of an error.
Change-Id: Iddea5bf342a4fc4b26002d8e98292f9dc57fa8cc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22885
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commands that blindly use PROTOC will try to execute "False" which is
very confusing for someone looking at the console output and error
messages. Instead, create a new environment setting HAVE_PROTOC which
is either true or false depending on if the protoc command exists and
passes muster.
Also, if there's an error running protoc, catch that and use it to
mark protoc as unavailable. The previous behavior was to supress errors
and just return an empty string instead, I assume with the expectation
that that would be an invalid version and fail later checks.
Change-Id: I1251b4e7e0e9894cdd3343e59498cc653b648b26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22883
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These tests assume the "end address" is not included in the range. This
exposed some bugs in addr_range.hh which have been fixed. Where
appropriate code comments in addr_range.hh have been extended to improve
understanding of the class's behavior.
Hard-coded AddrRange values in the project have been updated to take
into account that end address is now exclusive. The python params.py
interface has been updated to conform to this new standard.
Change-Id: Idd1e75d5771d198c4b8142b28de0f3a6e9007a52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22427
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Testing intmath.hh and intmath.cc. Here is the
list of the functions that are tested.
intmath.isPowerOf2, intmath.power, intmath.floorLog2,
intmath.ceilLog2, intmath.divCeil, intmath.roundUp,
intmath.roundDown. Other functions are not tested,
because they are not currently used and are dead code.
Change-Id: I150ac1b5cead93c6698a8c9e9cec80bd87ef181a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22081
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Mahyar Samani <msamani@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
The below list of functions were dead code and are now
deleted.
intmath.prevPrime, intmath.isPrime, intmath.leastSigBit,
intmath.floorPow2, intmath.ceilPow2, intmath.isHex,
intmath.isOct, intmath.isDec, intmath.hex2Int. The source
file intmath.cc is now effectively useless and deleted.
Change-Id: I28e4350056b8d03e02fecd5c7f7f9c62bc2df7ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22584
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
These namespaces were used to set up an environment/context where there
was an implicit guest namespace. This is an issue when there may be
multiple guest endiannesses which might be different. In cases where
we don't know what the guest endianness is, we can't rely on it being
an implicit part of our context since that would be ambiguous. In cases
where we do know, for instance in ISA specific code, we can just use
the endianness specific version that's appropriate for that context.
This also (somewhat) removes the assumption that there is a single
endianness that applies for a particular ISA. Practically speaking this
assumption will probably still stand though, since there would likely
be a non-trivial performance penalty to apply a configurable endianness
instead of a fixed one the compiler can optomize/remove.
Change-Id: I2dff338b58726d724f387388efe32d9233885680
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22374
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Members `tc` and `ongoingTranslation` were uninitialized in the constructor for
`QueuedPrefetcher::DeferredPacket`. If `ongoingTranslation` is not initialized to
`false` by default, some translation requests from queued prefetchers are not
properly handled and executions are nondeterministic.
Change-Id: Ia278f9e74847d6b847984d47f6a45643bae57794
Signed-off-by: Isaac Sánchez Barrera <isaac.sanchez@bsc.es>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22844
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Prior to this patch table walks were always cacheable unless
cacheability was globally disabled by SCTLR.C being 0. Arm allows to
select the memory attributes of table walks via the TCR registers.
For example the TCR.IRGN0 bits:
Inner cacheability attribute for memory associated with translation
table walks using TTBR0_EL1.
IRGN0 Meaning
0b00 Normal memory, Inner Non-cacheable.
0b01 Normal memory, Inner Write-Back Read-Allocate Write-Allocate
Cacheable.
0b10 Normal memory, Inner Write-Through Read-Allocate No
Write-Allocate Cacheable.
0b11 Normal memory, Inner Write-Back Read-Allocate No Write-Allocate
Cacheable.
Note: we check IRGNx bits (Inner Shareable domain) instead of ORGNx
(Outer Shareable domain) since in gem5 we consider everything as
Inner Shareable.
Change-Id: If472c218040029c9d165b056a052f522d48d4a82
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/+/22723
Tested-by: kokoro <noreply+kokoro@google.com>
In addition to the test, "#include base/logging.hh" was added to the
"byteswap.hh". It is is required to compile the header.
Added tests ByteswapTest.swap_byte64, ByteswapTest.swap_byte32,
ByteswapTest.swap_byte16, ByteswapTest.swap_byte, ByteswapTest.htog,
and ByteswapTest.gtoh. The file byteswap.hh is mostly templates.
Added test for BigEndianGuest and LittleEndianGuest namespaces.
Change-Id: I8870a55594ed439fe9e1fb333384f73261d1b1b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22080
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The new testlib library is looking for regressions walking from
a root folder. This by default points to the tests dir.
Since all regressions are supposed to live in the tests/gem5 subdir,
the patch is assigning the gem5 subdir as a root directory.
This will prevent the example garbage to be printed in the ci framework:
Exception thrown while loading
"/tmpfs/src/git/jenkins-gem5-prod/tests/long/fs/10.linux-boot/test.py"
Ignoring all tests in this file.
Exception thrown while loading
"/tmpfs/src/git/jenkins-gem5-prod/tests/long/fs/80.solaris-boot/test.py"
Ignoring all tests in this file.
[...]
Change-Id: Ia12c6bbeda4ceac71ccd38156ab1e3bb98b05c89
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/+/22726
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The function intmath.leastSigBit is ambiguous given
its name. It does not return the value of the least
significant bit, or the position of the least significant
set bit, but instead 2 to the power of the position of
the least significant set bit. It has thereby been removed
and the function intmath.isPowerOf2 has been refactored to
not require intmath.leastSigBit.
Change-Id: I22479c666cdd059865b8c73b70b5388f98a4584d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
