The code in the body of a DPRINTF will always be compiled, even if it's
disabled. If TRACING_ON is false, the if around it will short circuit to
false without actually running any code to check the specified
condition, and the body of the if will be elided by the compiler as
unreachable code.
This creates a more consistent environment whether TRACING_ON is on or
not, so that variables which are only used in DPRINTF don't have to be
guarded by their own TRACING_ON #ifs at the call site. It also ensures
that the code inside DPRINTF is always checked to be valid code, even if
the DPRINTF itself will never go off. This helps avoid syntax errors,
etc, which aren't found because of the configuration of the build being
tested with.
Change-Id: Ia95ae229ebcd2fc9828f62e87f037f76b9279819
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44988
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Only one is set up corrent, the one passed in from the constructor.
Others can be added with addThreadContext.
The inconsistency of adding one ThreadContext through the constructor
and others through addThreadContext isn't great, but this way we can
ensure that there is always at least one ThreadContext. I'm not sure
what the GDB stub should do if there aren't any threads. I don't think
that the protocol can actually handle that, judging from the
documentation I can find.
Change-Id: I9160c3701ce78dcbbe99de1a6fe2a13e7e69404e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44611
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>
Distinguish between the 'g' and 'c' subcommands. 'c' sets what thread(s)
should be continued or single stepped when those commands are used, and
'g' sets what thread(s) should be used for anything else. Also, insist
that all threads are used for continuing or single stepping.
Still complain if we're asked to switch threads, since we only have one
and we can't change to anything else.
Change-Id: Ia15c055baba48f75fc29ef369567535b0aa2c76b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44609
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This says *which* thread context you're replacing. Right now it's
implied that you're replacing the only thread context, but once we
support having multiple threads in the same GDB endpoint, that will no
longer be implied.
Change-Id: I5a789d12bbe195e019d5ccd8a005b5a6f16b9299
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44610
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
The existing send method takes a const char *, but frequently the class
wants to use it to send a std::string, also frequently after generating
that string with csprintf. Rather than force each call sight to add a
.c_str() and call csprintf, this change adds helpers which will accept a
std::string and call c_str for you, or accept a format const char * and
arguments and call csprintf for you (and then call .c_str() on the
result).
Change-Id: Ifcef5e09f6469322c6040374209972528c80fb25
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44607
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The remote GDB protocol encode thread IDs as positive integers, where 0
is a special value which indicates "pick any thread", and -1 is a
special value which indicates all threads.
The previous implementation would look like it worked handling the
special value -1 (for instance) because it see the '-' of "-1", stop
looking for digits, and return the default value 0.
This new implementation handles -1 as a special case, and will report an
error if no digits were found otherwise.
Also this change adds an encodeThreadId method to convert a ContextID
into a GDB thread ID by adding one to avoid the special value 0.
Change-Id: Iec54fbd9563d20a56011f48d50d69111ed1467b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44606
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
The systemc dir was not included in this fix.
First it was identified that there were only occurrences
at 0, 1, and 2 levels of indentation (and 2 of 2 spaces,
1 of 3 spaces and 2 of 12 spaces), using:
grep -nrE --exclude-dir=systemc \
"^ *enum [A-Za-z].* {$" src/
Then the following commands were run to replace:
<indent level>enum X ... {
by:
<indent level>enum X ...
<indent level>{
Level 0:
grep -nrl --exclude-dir=systemc \
"^enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^enum ([A-Za-z].*) \{$/enum \1\n\{/g'
Level 1:
grep -nrl --exclude-dir=systemc \
"^ enum [A-Za-z].* {$" src/ | \
xargs sed -Ei \
's/^ enum ([A-Za-z].*) \{$/ enum \1\n \{/g'
and so on.
Change-Id: Ib186cf379049098ceaec20dfe4d1edcedd5f940d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43326
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was checking that the breakpoint length was equal to the length of
the ISA specific MachInst type. Instead, force the ISA specific remote
GDB subclass to implement a check if it wants to, specific to its needs.
The base implementation will just approve of any length, which should be
fine with a well behaved GDB client.
Change-Id: Id7325b788f8445049855f8104082b8e4da1fe300
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39661
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This was mostly not used to begin with, but also when it was used, it
would obscure places where there were types, functions, etc, which were
switched between ISAs at compile time, and which would need to be
cleaned up to allow more than one ISA at a time.
Change-Id: Ieb372feff91b7e946b477fb78e54bcd0c2138966
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39655
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>
As the std namespace expands, it becomes more and more likely that
blanketly importing all its symbols will cause a collision. Also, when
it was imported, the std:: was used or left off arbitrarily, sometimes
inconsistently even in the same function signature.
Change-Id: Ie30cbab154b00c60433908a206c229230d2b109f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39536
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This abstraction will allow scheduling PCEvents for a particular
ThreadContext, all contexts on a CPU, all contexts in a system, etc.,
and delegates scheduling and removing events to each particular scope.
Right now the PCEventQueue is the only implementor of the PCEventSCope
interface.
Change-Id: I8fb62931511136229915c2e19d36aae7ffdec9df
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22099
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is done by implementing the Xfer:features:read packet of the GDB
remote protocol.
Before this commit, gem5 used the defaults of the GDB client.
With this commit, gem5 can inform the client which registers it knows
about. This allows in particular to support new registers which an older
GDB client does not yet know about.
The XML is not implemented in this commit for any arch, and falls back
almost exactly to previous behaviour. The only change is that now gem5
replies to the Supported: request which the GDB clients sends at the
beginning of the transaction with an empty feature list containing only
the mandatory PacketSize= argument.
Since the feature list does not contain qXfer:features:read, the GDB
client knows that the gem5 server does support the XML format and uses
its default registers as before.
Change-Id: I5185f28b00e9b9cc8245f4b4262cc324c3d298c1
Reviewed-on: https://gem5-review.googlesource.com/c/15137
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The size was not large enough for the 'G' packet on aarch64, which the
client sends to set registers.
This would lead to the stub not to be able to find the end of the input
packet and keep waiting forever.
Change-Id: Icb149f15a6c769371ebcb6ec5fbebc6170c31fc6
Reviewed-on: https://gem5-review.googlesource.com/c/14497
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
After refactoring the remote gdb interface, break_type is declared as
const function and is only used as a parameter to DPRINTF function
calls. This means that it is seen as unused when compiling
gem5.fast. This changeset fixes the warning.
Change-Id: Iea89b66c53c62341c043d8bd3838ebc27ee333bc
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/7741
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Fold the GDBListener class into the main BaseRemoteGDB class, move
around a bunch of functions, convert a lot of internal functions to
be private, move some functions into the .cc, make some functions
non-virtual which didn't really need to be overridden.
Change-Id: Id0832b730b0fdfb2eababa5067e72c66de1c147d
Reviewed-on: https://gem5-review.googlesource.com/7422
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
By setting the BaseCPU parameter wait_for_dbg_connection, the GDB
server blocks during initialisation waiting for the remote debugger to
connect before starting the simulated CPU.
Change-Id: I4d62c68ce9adf69344bccbb44f66e30b33715a1c
[ Update info message to include remote GDB port, rename param. ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3963
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
The new version modularizes the implementation of the various commands,
gets rid of dynamic allocation of the register cache, fixes some small
style problems, and uses exceptions to simplify error handling internal to
the GDB stub.
Change-Id: Iff3548373ce4adfb99106a810f5713b769df89b2
Reviewed-on: https://gem5-review.googlesource.com/3280
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Currently, if the remote gdb stub fails to read a byte from an incoming
packet because the connection has been dropped, the read call will return
anyway and the calling code will have no way to know something bad
happened. It might reattempt the read over and over again waiting for some
particular byte, doomed to never make forward progress.
This change modifies the remote GDB code so that if a read or write call
fails, it will instead detach from the debugger and continue. Before this
change, When simulating a port scan, ie connecting to the debugger port
and then immediately dropping the connection using this command:
nc -v -n -z -w 1 127.0.0.1 7000
gem5 would enter the previously described death spiral. After it, gem5
detaches from the bad connection and resumes execution. Subsequently
attaching with gdb was successful.
This code is written in a C centric style, and would benefit from some
refactoring.
Change-Id: Ie3c0bb35b9cfe3671d0f731e3907548bae0d292f
Reviewed-on: https://gem5-review.googlesource.com/3180
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Instead of scheduling another event, this patch adds a warning in case gdb
is attached multiple times and the first attachement event has not been
processed yet.
Currently, the wire format of register values in g- and G-packets is
modelled using a union of uint8/16/32/64 arrays. The offset positions
of each register are expressed as a "register count" scaled according
to the width of the register in question. This results in counter-
intuitive and error-prone "register count arithmetic", and some
formats would even be altogether unrepresentable in such model, e.g.
a 64-bit register following a 32-bit one would have a fractional index
in the regs64 array.
Another difficulty is that the array is allocated before the actual
architecture of the workload is known (and therefore before the correct
size for the array can be calculated).
With this patch I propose a simpler mechanism for expressing the
register set structure. In the new code, GdbRegCache is an abstract
class; its subclasses contain straightforward structs reflecting the
register representation. The determination whether to use e.g. the
AArch32 vs. AArch64 register set (or SPARCv8 vs SPARCv9, etc.) is made
by polymorphically dispatching getregs() to the concrete subclass.
The subclass is not instantiated until it is needed for actual
g-/G-packet processing, when the mode is already known.
This patch is not meant to be merged in on its own, because it changes
the contract between src/base/remote_gdb.* and src/arch/*/remote_gdb.*,
so as it stands right now, it would break the other architectures.
In this patch only the base and the ARM code are provided for review;
once we agree on the structure, I will provide src/arch/*/remote_gdb.*
for the other architectures; those patches could then be merged in
together.
Review Request: http://reviews.gem5.org/r/3207/
Pushed by Joel Hestness <jthestness@gmail.com>
The new single stepping implementation for x86 doesn't rely on any ISA
specific properties or functionality. This change pulls out the per ISA
implementation of those functions and promotes the X86 implementation to the
base class.
One drawback of that implementation is that the CPU might stop on an
instruction twice if it's affected by both breakpoints and single stepping.
While that might be a little surprising, it's harmless and would only happen
under somewhat unlikely circumstances.
The check which makes sure the length of the breakpoint being written is the
same as a MachInst is only correct on fixed instruction width ISAs. Instead of
incorrectly applying that check to all ISAs, this change makes that the
default check and lets ISA specific GDB classes override it.
This patch removes the assumption on having on single instance of
PhysicalMemory, and enables a distributed memory where the individual
memories in the system are each responsible for a single contiguous
address range.
All memories inherit from an AbstractMemory that encompasses the basic
behaviuor of a random access memory, and provides untimed access
methods. What was previously called PhysicalMemory is now
SimpleMemory, and a subclass of AbstractMemory. All future types of
memory controllers should inherit from AbstractMemory.
To enable e.g. the atomic CPU and RubyPort to access the now
distributed memory, the system has a wrapper class, called
PhysicalMemory that is aware of all the memories in the system and
their associated address ranges. This class thus acts as an
infinitely-fast bus and performs address decoding for these "shortcut"
accesses. Each memory can specify that it should not be part of the
global address map (used e.g. by the functional memories by some
testers). Moreover, each memory can be configured to be reported to
the OS configuration table, useful for populating ATAG structures, and
any potential ACPI tables.
Checkpointing support currently assumes that all memories have the
same size and organisation when creating and resuming from the
checkpoint. A future patch will enable a more flexible
re-organisation.
--HG--
rename : src/mem/PhysicalMemory.py => src/mem/AbstractMemory.py
rename : src/mem/PhysicalMemory.py => src/mem/SimpleMemory.py
rename : src/mem/physical.cc => src/mem/abstract_mem.cc
rename : src/mem/physical.hh => src/mem/abstract_mem.hh
rename : src/mem/physical.cc => src/mem/simple_mem.cc
rename : src/mem/physical.hh => src/mem/simple_mem.hh
This patch is adding a clearer design intent to all objects that would
not be complete without a port proxy by making the proxies members
rathen than dynamically allocated. In essence, if NULL would not be a
valid value for the proxy, then we avoid using a pointer to make this
clear.
The same approach is used for the methods using these proxies, such as
loadSections, that now use references rather than pointers to better
reflect the fact that NULL would not be an acceptable value (in fact
the code would break and that is how this patch started out).
Overall the concept of "using a reference to express unconditional
composition where a NULL pointer is never valid" could be done on a
much broader scale throughout the code base, but for now it is only
done in the locations affected by the proxies.
