From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B33F63858409; Wed, 13 Oct 2021 18:09:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B33F63858409 From: "simon.marchi at polymtl dot ca" To: gdb-prs@sourceware.org Subject: [Bug server/28392] gdb server no longer supports argument globbing and variable substitution Date: Wed, 13 Oct 2021 18:09:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: server X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simon.marchi at polymtl dot ca X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2021 18:09:42 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28392 --- Comment #6 from Simon Marchi --- (In reply to Michael Weghorn from comment #5) > (In reply to Michael Weghorn from comment #1) > > * "Plain" gdb by default has "startup-with-shell" enabled, but it still > > escapes special characters in args passed when running 'gdb --args ', > > as gdbserver does now after bea571ebd78ee29cb94adf648fbcda1e109e1be6 > > ("plain" GDB also uses 'construct_inferior_arguments', s. > > 'set_inferior_args_vector' in gdb/infcmd.c). > > Features (described in "startup-with-shell" section at [1]) like variab= le > > substitution, expanding wildcard characters and I/O redirection in the = shell > > only apply for args set in the GDB prompt or via the '--eval-command' a= rg, > > e.g. using 'run ' or 'set args '. >=20 > Note that for gdbserver (as opposed to how it works for plain gdb), args = set > via 'run ' or 'set args ' are now escaped as well > (s.a. PR 28446). > Here, it seems clear to me that no escaping should happen, so the remaini= ng > question is how to treat args passed directly on gdb/gdbserver invocation. Ok. > If, other than my original suggestion on comment 1, we want to have > gdbserver and gdb treat args passed directly on invocation ('gdb --args > ' or 'gdbserver ') the same, I essentially see two options: >=20 > 1) Don't escape args in either 'gdb --args ' nor 'gdbserver ', > i.e. revert to the previous behaviour in gdbserver and change the way that > gdb behaves, requiring that arguments passed via 'gdb --args ' are > escaped by the user as needed (as used to be the case for gdbserver before > commit bea571ebd78ee29cb94adf648fbcda1e109e1be6). >=20 > 2) Escape args for both 'gdb --args ' and 'gdbserver ' by > default, but add a new option for gdbserver to disable that (e.g. > '--no-escape-args'), so that the gdbserver behaviour can explicitly be > switched to the one before commit bea571ebd78ee29cb94adf648fbcda1e109e1be= 6. > 'gdb --args' behaviour remains unchanged in that case. >=20 > If we want to unify this, I currently tend to prefer option 2). I persona= lly > appreciate that just prepending a "gdb --args" to the usual program call > without having to think about any escaping is nice. By that argument, the current behavior of GDB, to escape arguments from the command line, is right then. This program prints the arguments it receives: $ ./a.out '$SHELL' [0] ./a.out [1] $SHELL $ ./gdb -nx -q --data-directory=3Ddata-directory -batch -ex r --args ./a.out '$SHELL' [0] /home/smarchi/build/binutils-gdb/gdb/a.out [1] $SHELL $ ./a.out "> out"=20=20=20=20=20=20=20 [0] ./a.out [1] > out $ ./gdb -nx -q --data-directory=3Ddata-directory -batch -ex r --args ./a.ou= t '> out'=20 [0] /home/smarchi/build/binutils-gdb/gdb/a.out [1] > out Imagine if GDB didn't escape the arguments, in that last example the "> out" would end up interpreted as SHELL redirection (unlike the non-GDB invokatio= n), it would be surprising I think. > At least for "simple" use cases where gdb is just invoked from a shell, I > *think* it often doesn't even make a huge difference whether globbing and > variable substitution (as opposed to I/O redirection) is already done by = the > shell from which gdb is invoked. >=20 > E.g. if I run this in a shell for option 1) >=20 > gdb --args ./myprogram $SHELL >=20 > it will finally run './myprogram /bin/bash' in gdb (in my case where > SHELL=3D/bin/bash), just as is the case for this command for option 2): >=20 > gdb --args ./myprogram '$SHELL' >=20 > just that variable expansion happens in the shell before the args are pas= sed > to gdb (case 1) as opposed to it being done by the shell invoked by GDB > (case 2). However, there are certainly more complex scenarios (I/O > redirection in any case, but also others where env variables are manually > set before execution or work directory is changed,...) where it does make= a > difference in practice. > However, at least for gdb, it's already possible to set unescaped args us= ing > '--eval-command=3D'set args ' if necessary. Indeed, with GDB you can fall back on "set args". But with gdbserver, you can't, and that might be a problem. So having a --no-escape-args could be a good option. And if we are adding it to gdbserver, we might as well add it= to gdb as well. i.e: $ ./gdb ... --args ./a.out '$SHELL' would show '$SHELL', and $ ./gdb ... --no-escape-args --args ./a.out '$SHELL' would show '/bin/bash' or whatever. > I'd guess that changing the way that 'gdb --args' behaves (option 1) would > be a "more breaking change" than changing gdbserver (option 2). > But honestly, I don't know what's the way that most people use gdb and you > can probably judge that in a much better way and will be happy to work on > the implementation that is considered most reasonable. >=20 > What do you think? I would probably lean towards option 1: - GDB has worked this way for a while, and it would probably break the workflow of more users than changing gdbserver - Given the examples above, I think the GDB behavior is somewhat sane - The "new" gdbserver behavior is now released in the wild, in gdbserver 1= 1.1 (IIUC). And it's what is in master today. We could always revert to the o= ld behavior as a "bug fix" in gdbserver 11.2, but that might end up even more confusing. So where we are standing today, we can see the change in gdbserver's behavior as being on purpose (to align gdbserver's behavior with gdb's), but add --no-escape-args to provide an escape hatch. There would be a third option, to revert gdbserver's behavior to be differe= nt than gdb's, and add an --escape-args switch. But I don't really like that,= as that makes gdb and gdbserver behave differently, whereas we try to make the= two converge. --=20 You are receiving this mail because: You are on the CC list for the bug.=