From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3830A3858439; Wed, 13 Oct 2021 06:43:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3830A3858439 From: "m.weghorn at posteo dot de" To: gdb-prs@sourceware.org Subject: [Bug server/28392] gdb server no longer supports argument globbing and variable substitution Date: Wed, 13 Oct 2021 06:43:29 +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: m.weghorn at posteo dot de 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 06:43:30 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28392 --- Comment #5 from Michael Weghorn --- (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 variable > substitution, expanding wildcard characters and I/O redirection in the sh= ell > only apply for args set in the GDB prompt or via the '--eval-command' arg, > e.g. using 'run ' or 'set args '. 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 remaining question is how to treat args passed directly on gdb/gdbserver invocation. (In reply to Simon Marchi from comment #4) > I think it's good if GDB and GDBserver have the same behavior. It's also > good if that behavior is predictable. I think we have to choose the > behavior that makes the most sense, make sure it works the same in GDB and > GDBserver, and stick to it / make sure it is properly tested. Whatever we > choose, I think some people will be unhappy (will see a change of behavior > in their use case). >=20 > Disregarding things work today, I think makes sense that when using > startup-with-shell, the arguments are passed unchanged to the shell > (although concatenated with spaces if more than one is given). Otherwise, > the option to run through a shell is kind of pointless. If, other than my original suggestion on comment 1, we want to have gdbserv= er and gdb treat args passed directly on invocation ('gdb --args ' or 'gdbserver ') the same, I essentially see two options: 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 escape= d by the user as needed (as used to be the case for gdbserver before commit bea571ebd78ee29cb94adf648fbcda1e109e1be6). 2) Escape args for both 'gdb --args ' and 'gdbserver ' by defau= lt, 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 bea571ebd78ee29cb94adf648fbcda1e109e1be6. 'gdb --args' behaviour rem= ains unchanged in that case. If we want to unify this, I currently tend to prefer option 2). I personally appreciate that just prepending a "gdb --args" to the usual program call without having to think about any escaping is nice. 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. E.g. if I run this in a shell for option 1) gdb --args ./myprogram $SHELL 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): gdb --args ./myprogram '$SHELL' just that variable expansion happens in the shell before the args are passe= d 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 using '--eval-command=3D'set args ' if necessary. 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. What do you think? --=20 You are receiving this mail because: You are on the CC list for the bug.=