These had been templated on a type, and then the width of that type was
considered the amount the PC should advance when executing straight line
code. That type was MachInst, which was loosely the size of an
instruction, but was practically whatever sized data type was fed into
the decoder at a time.
Instead of tying this to a type, this change moves it over to be a
simple number. This avoids a level of indirection, and also further
decouples the type the decoder might use as input from the instruction
size.
Change-Id: I797876a33d27e759c7a6e23a658179201fabfa47
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40176
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
By moving the installation of even the first ThreadContext out of the
constructor, it's possible to construct the stub separately. We can then
move the code that creates the stub out of the base class and into
architecture specific sub-classes.
Change-Id: I0dfd53a3135ebc98ec49acf81d83e58830bc365c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44618
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
There are two user visible effects of this change. First, all of the
threads for a particular workload are moved under a single GDB instance.
The GDB session can see all the threads at once, and can let you move
between them as you want.
Second, since there is a GDB instance per workload and not per CPU, the
wait_for_gdb parameter was moved to the workload.
Change-Id: I510410c3cbb56e445b0fbb1def94c769d3a7b2e3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44617
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When using remote GDB to debug an x86 simulated system within gem5, the
stub within gem5 needs to decide what arch the GDB instance expects.
That determines what format the blob of data with register values should
be.
Previously, gem5 would make that decision based on the current mode of
the target thread context. If the target was currently executing in 64
bit mode, that would imply that GDB was expecting 64 bit registers. If
not, then it was probably trying to debug a 32 bit program and would
expect 32 bit registers.
That works in many circumstances, but won't work if, for instance, a CPU
has not yet been initialized and is not running in its final, typical
mode, or if it's dipped into another mode to, for instance, run a user
mode program which is 32 bit under a 64 bit kernel.
This change modifies the GDB stub to first try to use the workload
object to determine what arch the GDB instance is most likely to assume.
This is a reasonably accurate representation for the arch GDB expects,
even though there isn't a direct, enforced link. It would be best if GDB
could just tell us what it expected, but I wasn't able to find any way
to get it to do that.
In most (all?) cases where someone would be using GDB to debug the guest
there will be a workload, and that workload will have a well defined
architecture. Since that isn't technically required though, this change
will still fall back to the old detection mechanism if it can't tell
from the workload, or if there is no workload in the first place.
Later revisions of the GDB interface may tie the remote GDB stub to the
workload object itself, in which case it *will* be possible to assume
that a workload object exists, and the workload object will be able to
explicitly select what GDB stub to use based on what it's running. In
the mean time, this seems like a fairly robust approximation of that.
Change-Id: I5059d48c28380e2fee5629d832acf95063a1a27a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44614
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When connecting to a thread, the remote GDB stub will try to wait for an
instruction boundary before proceeding. Since the CPU the thread context
is attached to may be inactive, it may not get around to reaching an
instruction boundary, and the event may not happen for an indefinite
period of time.
Instead, assume that inactive CPUs are already at instruction
boundaries, and trigger the event manually.
Change-Id: I9a67a49f9a52bdf9b1f0b88a1d173aa2bdfb5a16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44612
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Figure out more about what the CSR instructions are supposed to do at
decode/instruction construction time, instead of at run time. An
instruction will usually be constructed many fewer times than it will be
executed, so we can perform the work once and then use it many times.
Change-Id: I9941bb2555e67a6c738aa3dfdca1b4857427b71c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45521
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Loggers was previously declared as global variables, hence are unsafe to
be used inside other global objects' destructor (e.g. scMainFiber). This
CL makes them heap allocated objects hold by function static variables.
As a result:
1. The loggers never get destructed at the end of program, which makes
them safe to be used in global objects' destructor.
2. The loggers are constructed ondemand instead of relying on linker's
unknown way of ordering, which makes them safe to be used in global
objects' constructor.
Change-Id: Ieb499d2fa4c5c1c015324cb72b055115b0933ab8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46079
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
sim_clock::Int became sim_clock::as_int.
"as_int" was chosen because "int" is a reserved
keyword, and this namespace acts as a selector of
how to read the internal variables.
Another possibility to resolve this would be to
remove the namespaces "Float" and "Int" and use
unions instead.
Change-Id: I65f47608d2212424bed1731c7f53d242d5a7d89a
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45436
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
sim_clock::Float became sim_clock::as_float.
"as_float" was chosen because "float" is a reserved
keywords, and this namespace acts as a selector of
how to read the internal variables. Another
possibility to resolve this would be to remove the
namespaces "Float" and "Int" and use unions instead.
Change-Id: I7b3d9c6e9ab547493d5596c7eda080a25509a730
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45435
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
As part of recent decisions regarding namespace
naming conventions, all namespaces will be changed
to snake case.
X86Macroop became x86_macroop.
Ideally, this should probably be moved to inside the
X86ISA namespace, and renamed accordingly, but a macroop
namespace would probably generate a lot of conflicts.
Change-Id: I06bc0f33a4c1d95492df9397d7d70e5316b1b96b
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45400
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Clang 11 threw the following error: `anonymous non-C-compatible type
given name for linkage purposes by typedef declaration; add a tag name
here`.
Clang 11 enforces a restriction on giving non-C-compatible anonymous
structs a typedef name for linking purposes. This change to the C++
standard is discussed here http://wg21.link/p1766r1 and has been
retroactively applied to all C++ standard versions.
Change-Id: I87d84b9a3a842066cd4f61968ceee3fcad267b6f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45800
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This is patch is in regard to issues discussed here:
https://www.mail-archive.com/gem5-dev@gem5.org/msg39122.html
The aim of this patch is to set a potential fix, and to give more
valuable debugging information.
It is not known why Kokoro sometimes fails, but it may be due to the
Docker service not starting fully prior to execution of the tests
within a Docker container. As such a 2 second sleep has been added
between starting the Docker service and running the tests.
The pulling of the docker images has been separated out to run at the
start of testing. This should help us determine whether the issue lays
with the pulling of an image or the running of a container.
The bash debug flag `-x` has been set so the expansion of each line can
be determined upon the event of a failure.
This patch will be reverted if it is found to not solve the issue.
Change-Id: I0d2dd8a080f64296e55f4b6de9a036d94d19c8ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45999
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In this context, the decoder width is the number of bytes that are fed
into the decoder at once. This is frequently the same as the size of an
instruction, but in instructions with occasionally variable instruction
sizes (ARM, RISCV), or extremely variable instruction sizes (x86) there
may be no relation.
Rather than determining the amount of data to feed to the decoder based
on a MachInst type defined by each ISA, this new interface adds some new
properties to the base InstDecoder class each arch specific decoder
inherits from. These are the size of the incoming buffer, a pointer to
wherever that data should end up, and a mask for masking a PC value so
it aligns with the instruction size.
These values are filled in by a templated InstDecoder constructor which
is templated based on what would have historically been the MachInst
type.
Because the "moreBytes" method would historically accept a parameter of
type MachInst, this parameter has also been eliminated. Now, the
decoder's parent object should use the pointer and size values to fill
in the buffer moreBytes reads. Then when moreBytes is called, it just
uses the buffer without having to show what its type is externally.
Change-Id: I0642cdb6a61e152441ca4ce47d748639175cda90
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40175
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The existing template would apply the helper operator to *any* template
which took two types, regardless of what that template was. The
assumption was that those types *must* be STL containers, because no
other template takes two types, right?
Instead, this new version uses type traits to explicitly whitelist types
which the helper applies to. Currently the only type it seems to be used
with is std::vector, but by defining more specializations of
IsHelpedContainer, other types/templates can be enabled as well.
This is particularly important when moving to c++17, since the
std::string class would then apparently match the old overload. That
makes the << operator ambiguous and breaks the build.
Change-Id: Id283746a2ccced8882fa23e6f9e69fe22e206b70
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45901
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These classes belong in the ps2 namespace. Use this
opportunity to rename PS2Device as ps2::Device, and
PS2TouchKit as ps2::TouchKit.
Unfortunately, since the ps2::Mouse and ps2::Keyboard
namespaces are being deprecated, these names cannot be
used as of now to rename PS2Mouse and PS2Keyboard.
Change-Id: I9a57b87053a6a0acb380a919e09ab427fdb8eca4
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45395
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
