It boils down to this. With native: $ ./gdb -nx -q --data-directory=data-directory \ -ex r \ --args /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/args/args salut "''" toi produces: salut '' toi With extended-remote (with a gdbserver --multi listening on 1234): $ ./gdb -nx -q --data-directory=data-directory \ -ex "tar ext :1234" \ -ex "set remote exec-file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/args/args" \ -ex "set sysroot" \ -ex r \ --args /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/args/args salut "''" toi produces: salut \'\' toi I have not dug more than that, but I think that shows a bug in the extended-remote version. Here, I want to literally pass <single-quote><single-quote> as the argument to my program, such that strcmp ("''", argv[2]) == 0
Same goes for a newline. The argument passed on the shell is literally just a newline character, 0x0a. I added some HTML-like annotations to see where the args start and end, for clarity. With native: $ ./gdb -nx -q --data-directory=data-directory \ -ex r \ --args /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/args/args salut " " toi produces <arg1>salut</arg1> <arg2> </arg2> <arg3>toi</arg3> With extended-remote: ./gdb -nx -q --data-directory=data-directory \ -ex "tar ext :1234" \ -ex "set remote exec-file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/args/args" \ -ex "set sysroot" \ -ex r \ --args /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/args/args salut " " toi produces <arg1>salut</arg1> <arg2>' '</arg2> <arg3>toi</arg3> In the second case, single quotes appeared out of nowhere.
The master branch has been updated by Simon Marchi <simark@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=18263be7565782a9c07045a7a72d80c507a5be09 commit 18263be7565782a9c07045a7a72d80c507a5be09 Author: Simon Marchi <simon.marchi@efficios.com> Date: Thu Jun 17 09:41:59 2021 -0400 gdb/testsuite: gdb.base/args.exp: add KFAIL for native-extended-gdbserver This test tests passing arguments made of exactly two single-quotes ('') or a single newline character through the --args argument of GDB. For some reason, GDB adds some extra single quotes when transmitting the arguments to GDBserver. This produces some FAILs when testing with the native-extended-gdbserver board: FAIL: gdb.base/args.exp: argv[2] for one empty (with single quotes) FAIL: gdb.base/args.exp: argv[2] for two empty (with single quotes) FAIL: gdb.base/args.exp: argv[3] for two empty (with single quotes) FAIL: gdb.base/args.exp: argv[2] for one newline FAIL: gdb.base/args.exp: argv[2] for two newlines FAIL: gdb.base/args.exp: argv[3] for two newlines This is documented as PR 27989. Add some appropriate KFAILs. gdb/testsuite/ChangeLog: * gdb.base/args.exp: Check target, KFAIL if remote. (args_test): Add parameter and use it. Change-Id: I49225d1c7df7ebaba480ebdd596df80f8fbf62f0
That's also related to commit bea571ebd78ee29cb94adf648fbcda1e109e1be6 ("Use construct_inferior_arguments which handles special chars"). I'm looking at this in the context of PR 28392.
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f1f0a06d5b34231edd75fbd71a3be79097437f62 commit f1f0a06d5b34231edd75fbd71a3be79097437f62 Author: Andrew Burgess <aburgess@redhat.com> Date: Tue Sep 26 17:32:24 2023 +0100 gdbserver: fix handling of single quote arguments I noticed that passing arguments containing single quotes to gdbserver didn't work correctly: gdb -ex 'set sysroot' --args /tmp/show-args Reading symbols from /tmp/show-args... (gdb) target extended-remote | gdbserver --once --multi - /tmp/show-args Remote debugging using | gdbserver --once --multi - /tmp/show-args stdin/stdout redirected Process /tmp/show-args created; pid = 176054 Remote debugging using stdio Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) set args \' (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /tmp/show-args \' stdin/stdout redirected Process /tmp/show-args created; pid = 176088 2 args are: /tmp/show-args \' Done. [Inferior 1 (process 176088) exited normally] (gdb) target native Done. Use the "run" command to start a process. (gdb) run Starting program: /tmp/show-args \' 2 args are: /tmp/show-args ' Done. [Inferior 1 (process 176095) exited normally] (gdb) q The 'shows-args' program used here just prints the arguments passed to the inferior. Notice that when starting the inferior using the extended-remote target the second argument is "\'", while when running using native target the argument is "'". The second of these is correct, the \' used with the "set args" command is just to show GDB that the single quote is not opening an argument string. It turns out that the extra backslash is injected on the gdbserver side when gdbserver processes the arguments that GDB passes it, the code that does this was added as part of this much larger commit: commit 2090129c36c7e582943b7d300968d19b46160d84 Date: Thu Dec 22 21:11:11 2016 -0500 Share fork_inferior et al with gdbserver In this commit I propose removing the specific code that adds what I believe is a stray backslash. I've extended an existing test to cover this case, and I now see identical behaviour when using an extended-remote target as with the native target. This partially fixes PR gdb/27989, though there are still some issues with newline handling which I'll address in a later commit. During review I was pointed to this older series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ which also includes this fix as part of a larger set of changes. I'm giving a Co-Authored-By credit to the author of that original series. I believe this smaller fix brings some benefits on its own, though the original series does offer additional improvements. Once this is merged I'll take a look at rebasing and resubmitting the original series. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> Approved-By: Tom Tromey <tom@tromey.com>
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=67e6945b7e3a5c1577d19b9d83ee9be86c0a8424 commit 67e6945b7e3a5c1577d19b9d83ee9be86c0a8424 Author: Andrew Burgess <aburgess@redhat.com> Date: Wed Sep 27 17:54:15 2023 +0100 gdbserver: handle newlines in inferior arguments Similarly to how single quotes were mishandled, which was fixed two commits ago, this commit fixes handling of newlines in arguments passed to gdbserver. We already had a test that covered this, gdb.base/args.exp, which, when run with the native-extended-gdbserver board contained several KFAIL covering this situation. In this commit I remove the unnecessary, attempt to quote incoming newlines within arguments, and do some minimal cleanup of the related code. There is additional cleanup that can be done, but I'm leaving that for the next commit. Then I've removed the KFAIL from the test case, and performed some minimal cleanup there too. After this commit the gdb.base/args.exp is 100% passing with the native-extended-gdbserver board file. During review I was pointed to this older series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ which also includes this fix as part of a larger set of changes. I'm giving a Co-Authored-By credit to the author of that original series. I believe this smaller fix brings some benefits on its own, though the original series does offer additional improvements. Once this is merged I'll take a look at rebasing and resubmitting the original series. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27989 Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> Approved-By: Tom Tromey <tom@tromey.com>
Should now be fixed. As is mentioned in comment 3, this issue is a sub-set of the issue reported as bug PR 28392. The bigger issue is still not fixed, but this small part has now been resolved.