Currently, an access to an invalid address will cause GEM5 to exit with
a `!pkt.isError()` assertion failure. I was seeing this assertion while
running a baremetal RISC-V binary that faulted before the trap vector
had been configured and therefore tried to jump to address zero. With
this change we now print the invalid address and the type of access
(ifetch/load/store/amo) which makes debugging such a problem much easier.
For example, my faulting program now prints the following:
`panic: Instruction fetch ([0:0x4]) failed: BadAddressError [0:3] IF`
I also saw this assertion with a program that was dereferencing a NULL
pointer, which now prints a more helpful message:
`panic: Data fetch ([0x10:0x11]) failed: BadAddressError [10:10]`
Change-Id: Id983b74bf4688711f47308c6c7c15f49662ac495
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55203
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Port large DS read/write instructions from
https://gem5-review.googlesource.com/c/public/gem5/+/48342.
This implements the 96 and 128b ds_read/write instructions in a similar
fashion to the 3 and 4 dword flat_load/store instructions.
These instructions are treated as reads/writes of 3 or 4 dwords, instead
of as a single 96b/128b memory transaction, due to the limitations of
the VecOperand class used in the amdgpu code.
In order to handle treating the memory transaction as multiple dwords,
the patch also adds in new initMemRead/initMemWrite functions for ds
instructions. These are similar to the functions used in flat
instructions for the same purpose.
Change-Id: Iee2de14eb7f32b6654799d53dc97d806288af98f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55344
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Port the fixes for scalar source checks from arch-gcn3 at
https://gem5-review.googlesource.com/c/public/gem5/+/48344.
Scalar sources can either be a general-purpose register or a constant
register that holds a single value.
If we don't check for if the register is a general-purpose register,
it's possible that we get a constant register, which then causes all of
the register mapping code to break, as the constant registers aren't
supposed to be mapped like the general-purpose registers are.
This fix adds an isScalarReg check to the instruction encodings that
were missing it.
Change-Id: I30dd2d082a5a1dcc3075843bcefd325113ed1df6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55343
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, the test in realview64-simple-atomic-checkpoint.py runs the
default number of checkpoint cycles which is 5. Each of these cycles
takes a long time to run (approximately 5 minutes) which makes this test
take a long time to run to completion. We would get almost all of the
benefit of this test in a fraction of the time if we reduce the number
of iterations down to 3. This still has enough iterations to catch bugs
which would happen in one, a different class of bugs which happen when
checkpointing more than once, and even a third iteration for safety.
Because this test is one of the (if not the) most time consuming test in
the quick tests, reducing its length will significantly improve turn
around time when running all those tests.
That is especially valuable when running the tests multiple times to try
to iterate on a bug, or when sweeping through a series of changes trying
to identify the source of breakages. In cases where we might need to
identify failures which don't effect the end product of a series, ie where
a problem is introduced and then coincidentally fixed in a later change,
this is especially important since every individual change needs to be
checked, not just log(n) of the changes like in a binary search.
Ideally in the future we will also try to figure out why taking and
restoring from checkpoints takes so long so that each iteration of this
test is substantially less expensive. If we do that, we could consider
increasing the iteration count again.
Change-Id: Icfa2a391a4a7457d893f2063fab231d22e572deb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53123
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
When a user accidentally specifies the wrong path to a file, the
following error is received:
```
build/X86/base/loader/image_file_data.cc:111: panic: panic condition fd < 0 occurred: Failed to open file {path}.
```
For new users to gem5 this is confusing, and does not explicitly state
that the root cause of the issue is likely due to the path being
incorrect. Due to use of `panic_if`, this error was followed by a long
and unhelpful backtrace.
This patch expands the error message to state this error is typically
triggered when the specified path is incorrect. It also changes the
`panic_if` to a `fatal_if`. As noted in `src/base/logging.hh`, a
"panic() should be called when something happens that should never ever
happen", while a "fatal() should be called when the simulation cannot
continue due to some condition that is the user's fault". It is clear a
`fatal_if` is more suitable here as it is typically a user error. A
backtrace is not printed for `fatal`, only for `panic`.
Change-Id: I6e0a9bf4efb27ee00a40d77d74fd0dc99f9be4f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55183
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
Add initrd_filename and initrd_addr parameters to specify that an
initrd/initramfs should be loaded into memory from a file, just like the
DTB blob. The user must specify the initrd file, and they can specify
the initrd load address as well. However, in practice, it's expected
that the dev/machine backend will derive the initrd load address from
the dtb load address, which is how a bootloader would typically do it.
Change-Id: I6378927c2984b7ccdd1471486dd7803500ef5883
Signed-off-by: Alistair Delva <adelva@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54184
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a new API function, addBootData(), which allows the ports to specify
the size and load address of the initrd/initramfs via DeviceTree. This
uses the standard chosen nodes for initrd-start/initrd-end.
Update the addBootCmdline() to call addBootData() with no
initrd/initramfs so as to maintain backwards compatibility.
Change-Id: I7b1d5cf2a0b18685eaadf1d881434f3d48c45d8b
Signed-off-by: Alistair Delva <adelva@google.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54183
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are many SE mode system calls that are implemented
in src/sim/syscall_emul.cc or src/sim/syscall_emul.hh.
And they work well under X86 and ARM platforms. However,
they are not supported in se_workload.cc under the RISC-V
platform. This patch adds support for all the system calls
already implemented in syscall_emul.hh/cc to the RISC-V
platform (in arch/riscv/linux/se_workload.cc).
Change-Id: Ia47c3c113767b50412b1c8ade3c1047c894376cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54803
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Three changes below:
1. The m_stall_time was declared as statistics::Average, but
statistics::Average uses AvgStor as storage and this works as per-tick
average stat. In the case of m_stall_time, Scalar should be used to get
the calculation right.
2. The function used to get an enqueue time was changed since the
getTime() returns the time when the message was created.
3. Record the stall time only when the message is really dequeued
from the buffer (stall time is not evaluated when the message is moved
to stall map).
Change-Id: I090d19828b5c43f0843a8b735d3f00f312c436e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54363
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The `get_simstat` function in `src/python/m5/stats/gem5stats.py` was
returning an error when a non-Root Simobject was passed:
```
AttributeError: object 'PyTrafficGen' has no attribute 'name'
At:
build/NULL_MESI_Two_Level/python/m5/SimObject.py(1430): __getattr__
build/NULL_MESI_Two_Level/python/m5/stats/gem5stats.py(279): get_simstat
```
The issue was an assumption that SimObjects have a field `name`. They
do not. To get a SimObject's name the `get_name()` function must be
used. This patch fixes this issue.
In addition to this fix, the documentation in this function has been
improved to state more clearly what can be passed and what shall be
returned. Previously it was somewhat unclear.
Change-Id: I33538120015280bb6260ccf8eba6b75ff43d280e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54943
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
As noted here: https://gem5.atlassian.net/browse/GEM5-1133,
NVMInterface.py does not have a `controller()` function, which is used
by `configs/common/MemConfig.py` to obtain a memory controller for a
specific memory type selected. This patch adds a `controller()`
function to `NVNInterface.py` to avoid the reported error.
It should be noted that we do not enforce a rule that a memory type
must include a `controller()` function. `se.py`, and other scrips
that use `configs/common/MemConfigs.py`, should not rely on this
false assumption.
Change-Id: Ieba62f803d3b9f9c5c3c863d5a8c4ca16c5e5e82
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54923
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There is currently a "--gold-linker" option, which tells SCons to use
the gold linker. This puts the gold linker in a special position where
it has its own command line option, and makes it impossible to
explicitly select any other linker.
This change adds a --linker option which can be set to "bfd" (the
default gnu linker), "gold" (the gnu gold linker), or "lld" which is the
clang linker. If none is specified, SCons will let the compiler fall
back to whatever its default is.
The --gold-linker option is modified so that it just sets the --linker
option for you. Because of how SCons handles adding command line
options, there isn't a good way to complain if both it and --linker is
used, nor is there a good way to warn that the user is using a
deprecated command line option. A warning is in the help text for that
option now, though.
If the gold linker is selected, this change also sets the --threads
option, and sets the --thread-count option. This tells the gold linker
to run multi-threaded to speed up linking. Apparently the gold linker
must have been built with an option that enables threading for these
options to have any effect. If threads and LTO are both enabled, the
gold linker segfaults. To avoid that problem, we don't add --threads if
LTO has been enabled.
This change also enables a new configuration, where lld, the clang
linker, can be used with gcc. Unfortunately the format of LTO
information gcc/g++ generates is not compatible with lld, and so if you
set the linker to lld and enable LTO, you'll probably get errors like
not being able to find the symbol "main".
This change also allows you to select the default gnu linker ("bfd")
when using clang, although it's not clear why you would want to do that.
Change-Id: Ib37030431527f5d0bc626e9594b2e1142df889be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49003
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
rocBLAS builds for all targets by default, but it requires we set the
HCC_AMDGPU_TARGET env variable to all the targets we want to build for.
This change explicitly sets all the gfx versions we intend to support in
gem5, and removes the extraneous "-a all" from the install command.
Additionally, doing this allowed for DNNMark to run on gfx902.
Change-Id: Id1a00433beaa23f6935c12073d5bddc38431886b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54623
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This resource has been deprecated in favor of 'x86-ubuntu-18.04-img'. In
practise, these are the same resource (i.e., the same disk image), but
we deprecate 'x86-ubuntu-img' as 'x86-ubuntu-18.04-img' is more explicit
on what the disk image contains. Going forward we may want different
disk image resources with different Ubuntu versions, and we want it to
be clear what the user is retrieving.
Change-Id: I06b08e6b65cf431067ffda35ebd10d419068d073
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54583
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The 'resources.json' file in gem5 resources is used to lookup resources.
The stdlib resource downloader was hardcoded to the 'resources.json'
stored in the gem5 resources stable branch. This change allows the gem5
downloader to obtain the specific resources.json.
Change-Id: Ie119ed9326b359055bf5bc347ca89336a5cc2e5d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54466
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
