In commit 83b14e56, getVirtProxy is replaced by inline ternary operators
to decide between FS or SE version. However, dynamic dispatch will not
work in this scenario and the virtual function of SETranslatingPortProxy
will not be called. It may lead to failure in m5op read_file in SE mode.
Change-Id: I9b5f757096cfdbd6fb8bc14b1b0e02245703a0ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62611
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The previous implementation used the physical memory view when reporting
memory back to GDB. This circumvents MMUs and caches, and leads to wrong
backtraces at the least.
Current architectures support EL3, EL2, and EL1/EL0, and the Iris
interface presents a Msn that corresponds to that (`0x10ff`), see
table "Canonical memory space numbers" in the Iris user guide.
As GDB expects the view of the processor when querying memory (e.g. for
backtraces), this will allow proper backtraces.
Not sure if there is an implicit way of expressing memory attributes
(like in Lauterbach with the access modifiers before address
specifications), or if there is a need to implement special monitor
commands. But for the common use, using `CurrentMsn` should be the
correct choice.
Change-Id: Ibd14c1f94163105539a7fb9132550fe713b5c295
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61951
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The Linux Kernel's printk mechanism and data structures were
overhauled in v5.10. This patch updates gem5's facility to dump the
kernel Dmesg buffer on kernel panic to account for these changes.
The new mechanism splits the Demsg ringbuffer into three separate
ringbuffers, one containing the message data, one containing
descriptors used for lock-free synchronisation, and one containing the
message infos. For a detailed description please see the header of
`kernel/printk/printk_ringbuffer.c` in the Linux source code.
The new gem5 implementation tests for the correct version to
run (pre-v5.10 or post-v5.10) by testing for the presence of symbols
in the kernel. The new, post-v5.10 dump code is templated on types
compatible with the kernel's atomic_long_t to account for differences
between the 64-bit and 32-bit Linux kernels.
Because the new Dmesg buffer dump code in gem5 is intended for
disaster recovery, it intentionally prints the full Dmesg buffer with
minimal checking of the validity of the messages. Partially finished
and/or uncommitted messages will be printed along with the finalised
messages.
Change-Id: I62ac20735e0679f1ba2062ca7bb13692a5ca1eae
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59509
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This class implements a generic memoization object:
It takes a function as a constructor argument and memoizes
it. Every time the function gets invoked through the Memoizer object
the result gets saved in the internal cache, ready
to be retrieved next time an invokation is made with the same
arguments.
Example usage:
int fibonacci(int n);
Memoizer fibonacci_memo(fibonacci);
fibonacci_memo(5);
There are two ways to discard a memoization
1) Delete the Memoizer object
2) Use the Memoizer::flush method
In some cases there is little or no reason to discard a memoization
(like in the fibonacci example, where fibonacci(k) always returns
the same value for the same input k)
The memoizer could be used in more complex cases, where a change in
the global state affects the output of the function, which
effectively invalidates the cached results.
It is up to the client to understand when memoization is no longer
valid and to flush the result cache as a consequence.
Change-Id: I6cf496b2aef5a66f5375a627165b2cb2e3a1bfc2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59149
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add an utility class that provides a service for another process
query and get the fd of the corresponding region in gem5's physmem.
Basically, the service works in this way:
1. client connect to the unix socket created by a SharedMemoryServer
2. client send a request {start, end} to gem5
3. the server locates the corresponding shared memory
4. gem5 response {offset} and pass {fd} in ancillary data
mmap fd at offset will provide the client the view into the physical
memory of the request range.
Change-Id: I9d42fd8a41fc28dcfebb45dec10bc9ebb8e21d11
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57729
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Boris Shingarov <shingarov@labware.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Current implementation prevents customers from performing zero
initialize on BitUnion class. Customers would get unexpected results
when writing `BitUnion{}`. Changing the default constructor to default
can solve this issue.
After changing the default constructor, the test failed with unused
variable. I also change one with zero initializer and make the other
with maybe_unused label.
```
tests/build/ARM/base/bitunion.test.cc:133:14: error: 'emptySixteen' defined but not used [-Werror=unused-variable]
133 | EmptySixteen emptySixteen;
| ^~~~~~~~~~~~
tests/build/ARM/base/bitunion.test.cc:132:16: error: 'emptyThirtyTwo' defined but not used [-Werror=unused-variable]
132 | EmptyThirtyTwo emptyThirtyTwo;
| ^~~~~~~~~~~~~~
```
Change-Id: Icbed36b3fa6751cbda63e84443eaab6d865d9bd6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57730
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The original implementation does not cleanup the socket after it failed
to listen. However, the API doesn't give our user a way to bypass the
bind part and the next try will always break at the bind call.
Furthermore, the next failure will be EINVAL instead of EADDRINUSE so
gem5 will just abort without giving any meaningful message.
In this CL we cleanup the socket if we failed to invoke listen, so the
user can retry with a clean state and even retry on another port.
Test: Try to launch two gem5 that both bind to gdb port (7000) and
repeat it for 100 times.
Change-Id: I7272ea3c3b6ab56e4b904f3a3a45ed389d00dd05
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55943
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nathanael Premillieu <nathanael.premillieu@huawei.com>
These registers used to be accessed with a two dimensional index, with
one dimension specifying the register, and the second index specifying
the element within that register. This change linearizes that index down
to one dimension, where the elements of each register are laid out one
after the other in sequence.
Change-Id: I41110f57b505679a327108369db61c826d24922e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49148
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.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 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>
The setup() method of ScalarPrint, inherited from BasePrint, is not
called by its constructor, and is not called on the ScalarPrint "print"
in DistPrint::operator(). This sets most of the values in BasePrint.
Instead, this method sets these values itself based on the values of the
DistPrint itself.
Unfortunately it looks like this method forgot to set enableUnits, which
ends up otherwise uninitialized when the printUnits method is called.
This change fixes that.
Change-Id: Ib1ea78796539f6d9222d19dad597a4e64aa69808
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52483
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
There are two kinds of stats in the system. The old one requires an
unique name, while the new one requires an local name. The setName
function has a flag to specify the difference. In the constructor of
InfoAccess, it sets correct flag to the setName function. However, if
you set the name later with the setter, it wouldn't set the flag for
you. This leads the name conflict in new style stats with same local
name. We should also pass the correct flag in the name setter.
Change-Id: I0fcaad3cca65d0f2859c5f6cb28a00813a026a0c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52323
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a unit test for sim/serialize.hh.
==Bugs==
arrayParamIn cannot parse strings with spaces. Since spaces
are used as delimiters, strings containing spaces are parsed
as multiple entries of the array. The test that checks for
this has been disabled.
==Unexpected Behavior==
Serialization has an unexpected behavior when returning to
previous scopes. For example,
...
SCS scs(cpt, "S1")
paramOut(cpt, "param1", integer1)
{
SCS scs_2(cpt, "S2")
paramOut(cpt, "param2", integer2)
}
paramOut(cpt, "param3", integer3)
will generate the output:
...
[S1]
param1=1
[S2]
param2=2
param3=3
But the user might expect:
...
[S1]
param1=1
[S2]
param2=2
[S1]
param3=3
==Incovenient Behavior==
arrayParamIn with a std::array parameter is slightly
incovenient, since the raw data pointer must be extracted.
It may be worth it to add a template specialization.
==Not Tested==
paramInImpl is not being directly tested because it should
not be used as an external API - paramIn and optParamIn
should be used instead.
arrayParamIn with an InsertIterator parameter is not being
directly tested because the other versions should be used
instead.
Change-Id: If0c8f045aa317790d5fcb32e48629b113b62efc5
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41337
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Expand exclude to work with an AddrRange or AddrRangeList, define
versions to exclude both from an AddrRangeList, and make all available
through subtraction operators. Add -= operators for AddrRangeList with
another AddrRangeList or AddrRange.
Change-Id: Ic48f0c45a4809dbc51e1d3133e8319134aabe29e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50347
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
We go through the trouble of defining an AddrRangeList typedef, but then
we don't use it consistently and use std::vector<AddrRange> instead.
This change converts the exclude method from using
std::vector<AddrRange> to AddrRangeList, and also adds a constructor
which takes an AddrRangeList.
Because there is a lot of code which uses the std::vector based
constructor, this change does not remove that method.
Change-Id: I1a03b25990025688aa760a67d3e7a2e8141384ce
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50344
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
