The remote protocol provides a monitor query. This query allows to
provide a implementation defined behavior in the stub.
I proposed to use this command as a way to quit simulation with a
message provided by the GDB client.
Thus calling "monitor my_message" in the client will exit the
simulation with the exit message "GDB_MONITOR:my_message".
This is implemented through a derived class based on
GlobalSimLoopExitEvent and a small addition to the based class that adds
a clean method that will be called when returning siumation after the
Event.
Change-Id: Ib5fda569edcf6733cbcc6240ef6d2ec4dc6502ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63538
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The `Addr line_addr` in "src/mem/snoop_filter.cc" variable was only
used in an assert, stripped when compiling gem5.fast.
Clang-13 throws a warning for this variable. This has been fixed by
merging the variable and associated logic into the assert statement.
The variables in inet.cc and Sequencer.cc were also causing an 'unused
variable' warning to be thrown due to variables that were only used in
assert statements. In these cases the logic could not be moved into the
assert statement and, as such, the `GEM5_VAR_USED` MACRO is used to
remove this warning.
Change-Id: I6511d0863608c38b79e4558c7dcf35a323fe8362
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64171
Reviewed-by: Kunal Pai <kunpai@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Adding a small python function that allows to display
messages directly in GDB from the python interpreter.
This function is inside the Workload SimObject
(The stub is not a SimObject).
ex:
system.workload.sendToGdb("message to display")
Change-Id: I46ddae079b10d298743e023f95bf15608f50e358
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63531
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The remote protocol describes 2 type of stop respond packet.
S packets (which are the one that where used before) and T packets.
T packet support multiple fields to give more information about:
- thread/core which stopped
- registers values
- A stopReason string that are predefined value and that can
differentiate between different types of break that would
issue the same signal.
Change-Id: Id8ed7115898bf825dd14395f586c393d6f5aa2bc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63528
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Add a try_getbyte function that feature a timeout. This function uses
select to detect update on the file descriptor used to communicate with
the remote.
It is used to implement getbyte and to clean the file
descriptor before sending a message with send.
Now getbyte and send can recover from certains error like interruption
by other signals (EINTR) or delays causing the remote server to send
error packet to the stub.
Change-Id: Ie06845ba59dee0ad831632d5bc2b15132c9d5450
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63526
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
