GDB holds the inferior arguments as a single string. Currently when
GDB needs to pass the inferior arguments to a remote target as part of
a vRun packet, this is done by splitting the single argument string
into its component arguments by calling gdb::remote_args::split, which
uses the gdb_argv class to split the arguments for us.
The same gdb_argv class is used when the user has asked GDB/gdbserver
to start the inferior without first invoking a shell; the gdb_argv
class is used to split the argument string into it component
arguments, and each is passed as a separate argument to the execve
call which spawns the inferior.
There is however, a problem with using gdb_argv to split the arguments
before passing them to a remote target. To understand this problem we
must first understand how gdb_argv is used when invoking an inferior
without a shell.
And to understand how gdb_argv is used to start an inferior without a
shell, I feel we need to first look at an example of starting an
inferior with a shell.
Consider these two cases:
(a) (gdb) set args \$VAR
(b) (gdb) set args $VAR
When starting with a shell, in case (a) the user expects the inferior
to receive a literal '$VAR' string as an argument, while in case (b)
the user expects to see the shell expanded value of the variable $VAR.
If the user does 'set startup-with-shell off', then in (a) GDB will
strip the '\' while splitting the arguments, and the inferior will be
passed a literal '$VAR'. In (b) there is no '\' to strip, so also in
this case the inferior will receive a literal '$VAR', remember
startup-with-shell is off, so there is no shell that can ever expand
$VAR.
Notice, that when startup-with-shell is off, we end up with a many to
one mapping, both (a) and (b) result in the literal string $VAR being
passed to the inferior. I think this is the correct behaviour in this
case.
However, as we use gdb_argv to split the remote arguments we have the
same many to one mapping within the vRun packet. But the vRun packet
will be used when startup-with-shell is both on and off. What this
means is that when gdbserver receives a vRun packet containing '$VAR'
it doesn't know if GDB actually had '$VAR', or if GDB had '\$VAR'.
And this is a huge problem.
We can address this by making the argument splitting for remote
targets smarter, and I do have patches that try to do this in this
series:
https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com
That series was pretty long, and wasn't getting reviewed, so I'm
pulling the individual patches out and posting them separately.
This patch doesn't try to improve remote argument splitting. I think
that splitting and then joining the arguments is a mistake which can
only introduce problems. The patch in the above series which tries to
make the splitting and joining "smarter" handles unquoted, single
quoted, and double quoted strings. But that doesn't really address
parameter substitution, command substitution, or arithmetic expansion.
And even if we did try to address these cases, what rules exactly
would we implement? Probably POSIX shell rules, but what if the
remote target doesn't have a POSIX shell? The only reason we're
talking about which shell rules to follow is because the splitting and
joining logic needs to mirror those rules. If we stop splitting and
joining then we no longer need to care about the target's shell.
Clearly, for backward compatibility we need to maintain some degree of
argument splitting and joining as we currently have; and that's why I
have a later patch (see the series above) that tries to improve that
splitting and joining a little. But I think, what we should really
do, is add a new feature flag (as used by the qSupported packet) and,
if GDB and the remote target agree, we should pass the inferior
arguments as a single string.
This solves all our problems. In the startup with shell case, we no
longer need to worry about splitting at all. The arguments are passed
unmodified to the remote target, that can then pass the arguments to
the shell directly.
In the 'startup-with-shell off' case it is now up to the remote target
to split the arguments, though in gdbserver we already did this, so
nothing really changes in this case. And if the remote target doesn't
have a POSIX shell, well GDB just doesn't need to worry about it!
Something similar to this was originally suggested in this series:
https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/
though this series didn't try to maintain backward compatibility,
which I think is an issue that my patch solves. Additionally, this
series only passed the arguments as a single string in some cases,
I've simplified this so that, when GDB and the remote agree, the
arguments are always passed as a single string. I think this is a
little cleaner.
I've also added documentation and some tests with this commit,
including ensuring that we test both the new single string approach,
and the fallback split/join approach.
I've credited the author of the referenced series as co-author as they
did come to a similar conclusion, though I think my implementation is
different enough that I'm happy to list myself as primary author.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392
Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>
This patch gives gdbserver the ability to omit the 's' reply to
'vCont?'. This tells gdb that hardware single-step is definitely not
supported, causing it to fall back to using software single-step.
This is useful for testing the earlier change to
maybe_software_singlestep.
Approved-By: Andrew Burgess <aburgess@redhat.com>
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Add a new 'error_message' feature to the qSupported packet. When GDB
supports this feature then gdbserver is able to send
errors in the E.errtext format for the qRcmd and m packets.
Update qRcmd packet and m packets documentation as qRcmd newly
accepts errors in a E.errtext format.
Previously these two packets didn't support E.errtext style errors.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
Enable SME support in gdbserver by adjusting the usual fields. There is
not much to this patch because the code is either in gdb or it is shared
between gdbserver and gdb. One exception is the bump to gdbserver's
PBUFSIZ from 18432 to 131104.
Since the ZA register can be quite big (256 * 256 bytes), the g/G remote
packet will also become quite big
From gdbserver/tdesc.cc:init_target_desc, I estimated the new size should
be at least (2 * 256 * 256 + 32), which yields 131104.
It is also unlikely we will find a process starting up with SVL set to 256.
Ideally we'd adjust the packet size dynamically based on what we need, but
for now this should do.
Please note we have the same limitation for SME that we have for SVE, and
that is the fact gdbserver cannot communicate vector length changes to gdb
via the remote protocol.
Thiago is working on this improvement, which hopefully will be able to be
adapted to SME in an easy way.
Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
I've long wanted to remove 'struct buffer', and thanks to Simon's
earlier patch, I was finally able to do so. My feeling has been that
gdb already has several decent structures available for growing
strings: std::string of course, but also obstack and even objalloc
from BFD and dyn-string from libiberty. The previous patches in this
series removed all the uses of struct buffer, so this one can remove
the code and the remaining #includes.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
This patch adds the generic remote bits to gdbserver so it can check for memory
tagging support and handle fetch tags and store tags requests.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* remote-utils.cc (decode_m_packet_params): Renamed from ...
(decode_m_packet): ... this, which now calls decode_m_packet_params.
Make char * param/return const char *.
(decode_M_packet): Use decode_m_packet_params and make char * param
const char *.
* remote-utils.h (decode_m_packet_params): New prototype.
(decode_m_packet): Constify char pointers.
(decode_M_packet): Likewise.
* server.cc (create_fetch_memtags_reply)
(parse_store_memtags_request): New
functions.
(handle_general_set): Handle the QMemTags packet.
(parse_fetch_memtags_request): New function.
(handle_query): Handle the qMemTags packet and advertise memory
tagging support.
(captured_main): Initialize memory tagging flag.
* server.h (struct client_state): Initialize memory tagging flag.
* target.cc (process_stratum_target::supports_memory_tagging)
(process_stratum_target::fetch_memtags)
(process_stratum_target::store_memtags): New methods.
* target.h: Include gdbsupport/byte-vector.h.
(class process_stratum_target) <supports_memory_tagging>
<fetch_memtags, store_memtags>: New class virtual methods.
(target_supports_memory_tagging): Define.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
There is a developer only feature in gdbserver that provides a
command line option --disable-packet that prevents some packets from
being sent, which is used to increase test coverage within GDB.
This commit extends this mechanism to prevent GDBserver from sending
the T stop reply packets, instead limiting GDBserver to only send the
S stop reply packets.
The S stop reply packet is part of the older target control mechanism,
which has design flaws that were worked around with the introduction
of the newer target control mechanism, which uses the T stop reply
packet.
Limiting GDBserver to use S stop packets instead of T stop packets
will, inevitably, mean that GDBserver doesn't function correctly in
many cases involving multiple threads, however, I don't think this is
too important, this is a developer only feature, intended to allow us
to test GDB.
A new test that makes use of this feature will be added in the next
commit.
gdbserver/ChangeLog:
* remote-utils.cc (prepare_resume_reply): Add ability to convert T
reply into an S reply.
* server.cc (disable_packet_T): New global.
(captured_main): Set new global when appropriate.
* server.h (disable_packet_T): Declare.
This patch moves gdbserver to the top level.
This patch is as close to a pure move as possible -- gdbserver still
builds its own variant of gnulib and gdbsupport. Changing this will
be done in a separate patch.
[v2] Note that, per Simon's review comment, this patch changes the
tree so that gdbserver is not built for or1k or score. This makes
sense, because there is apparently not actually a gdbserver port here.
[v3] This version of the patch also splits out some configury into a
new file, gdbserver/configure.host, so that the top-level configure
script can simply rely on it in order to decide whether gdbserver
should be built.
[v4] This version adds documentation and removes some unnecessary
top-level dependencies.
[v5] Update docs to mention "make all-gdbserver" and change how
top-level configure decides whether to build gdbserver, switching to a
single, shared script.
Tested by the buildbot.
ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver.
* gdbserver: New directory, moved from gdb/gdbserver.
* configure.ac (host_tools): Add gdbserver.
Only build gdbserver on certain systems.
* Makefile.in, configure: Rebuild.
* Makefile.def (host_modules, dependencies): Add gdbserver.
* MAINTAINERS: Add gdbserver.
gdb/ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
* README: Update gdbserver documentation.
* gdbserver: Move to top level.
* configure.tgt (build_gdbserver): Remove.
* configure.ac: Remove --enable-gdbserver.
* configure: Rebuild.
* Makefile.in (distclean): Don't mention gdbserver.
Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e
