[Bug server/28392] gdb server no longer supports argument globbing and variable substitution

["m.weghorn at posteo dot de" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28392

--- Comment #5 from Michael Weghorn <m.weghorn at posteo dot de> ---
(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 <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 shell
> only apply for args set in the GDB prompt or via the '--eval-command' arg,
> e.g. using 'run <PROGRAM> <ARGS>' or 'set args <ARGS>'.

Note that for gdbserver (as opposed to how it works for plain gdb), args set
via 'run <PROGRAM> <ARGS>' or 'set args <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).
> 
> 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 gdbserver
and gdb treat args passed directly on invocation ('gdb --args <ARGS>' or
'gdbserver <ARGS>') the same, I essentially see two options:

1) Don't escape args in either 'gdb --args <ARGS>' nor 'gdbserver <ARGS>', i.e.
revert to the previous behaviour in gdbserver and change the way that gdb
behaves, requiring that arguments passed via 'gdb --args <ARGS>' are escaped by
the user as needed (as used to be the case for gdbserver before commit
bea571ebd78ee29cb94adf648fbcda1e109e1be6).

2) Escape args for both 'gdb --args <ARGS>' and 'gdbserver <ARGS>' 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 bea571ebd78ee29cb94adf648fbcda1e109e1be6. 'gdb --args' behaviour remains
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=/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 passed 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='set args <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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.