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

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

[nikita6 at bk dot ru]

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

            Bug ID: 28392
           Summary: gdb server no longer supports argument globbing and
                    variable substitution
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: server
          Assignee: unassigned at sourceware dot org
          Reporter: nikita6 at bk dot ru
  Target Milestone: ---

Due to change in the way arguments are handled by gdbserver (bisected as commit
bea571ebd78ee29cb94adf648fbcda1e109e1be6), it is no longer possible to do shell
variable substitution, globbing and inferior output redirection via command
line.

Steps to reproduce:
1) Run gdbserver
gdbserver --startup-with-shell localhost:5006 ls ">test.txt"

2) (in another terminal) Connect to it with gdb
gdb --eval-command='target remote localhost:5006' --eval-command='c'
--eval-command='q'

Before the offending commit you would get:

Process ls created; pid = 2060713
Listening on port 5006
Remote debugging from host 127.0.0.1, port 48496

Child exited with status 0


and a file test.txt created

After the offending commit you would get:

Process ls created; pid = 2060582
Listening on port 5006
Remote debugging from host 127.0.0.1, port 48494
ls: cannot access '>test.txt': No such file or directory

Child exited with status 2


It appears that the commit was trying to fix PR 25893, which was about handling
arguments with spaces. It appears that it was too restrictive about escaping
though, not allowing the usage of any of the shell features

Those features are actually documented in --no-startup-with-shell flag help:

> Exec PROG directly instead of using a shell.
> Disables argument globbing and variable substitution
> on UNIX-like systems.

(with the commit applied and flag --startup-with-shell used this does not
work).

The problem was discovered when using bazel extension for CLion (tracked at
https://github.com/bazelbuild/intellij/issues/2958). The plugin executes
gdbserver, redirecting gdbserver's and interior's outputs to different files.
Due to changed parsing inferior gets something like
`1>/tmp/gdbserver_wrapper.KxJr27Av/inferior.out
2>/tmp/gdbserver_wrapper.KxJr27Av/inferior.err` as arguments when using gdb
10.2, which is.. Inconvenient to say the least.

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

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

[nikita6 at bk dot ru]

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

Nikita Strygin <nikita6 at bk dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nikita6 at bk dot ru

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

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

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m.weghorn at posteo dot de,
                   |                            |simark at simark dot ca

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

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

[m.weghorn at posteo dot de]

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

--- Comment #1 from Michael Weghorn <m.weghorn at posteo dot de> ---
Thanks for the detailed report. I have to admit I was not aware of the features
my commit broke, nor the '--no-startup-with-shell' arg for gdbserver.

Some thoughts/observations:

* Args with spaces still don't work when using the '--no-startup-with-shell'
arg for gdbserver. (Before bea571ebd78ee29cb94adf648fbcda1e109e1be6, such args
were silently split into multiple args as described in PR 25893, now gdbserver
exits saying "can't handle command-line argument containing whitespace".) That
should IMHO be fixed independently of the case where 'startup-with-shell' is
enabled.

* What gdb essentially does on UNIX-like systems when 'startup-with-shell' is
enabled is to run the program in a shell using "<SHELL> -c '<EXEC> <ARGS>'".

* "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>'.

* So far, I see no way to make both, the features described here as well as the
case with spaces in arguments (as described in PR 25893) work at the same time
for args passed on the command line when 'startup-with-shell' is enabled. From
how I understand it, just escaping specific characters wouldn't help. E.g. when
only escaping spaces, an
'>out.txt 2>err.txt' would then still not work as previously/expected, would
behave like an unescaped '>"out.txt 2" >"err.txt"'.

Given that, the most reasonable approach I can currently come up with to bring
back globbing, variable substitution and I/O redirection in the shell:

* for the case where 'startup-with-shell' is enabled, change back to the
behaviour before commit bea571ebd78ee29cb94adf648fbcda1e109e1be6

    * accept that gdbserver and "plain" gdb treat args passed via command line
differently by default (i.e. when '--no-startup-with-shell' is not explicitly
set for gdbserver)

    * given that args are passed to the shell in an unmodified way, the
scenario from PR 25893 is then possibly supposed to be regarded as a feature,
not a bug...

* As opposed to the expectation in PR 25893, args with spaces and special
characters then need to be escaped/quoted by the user when startup-with-shell
is enabled for gdbserver, e.g. by running

    gdbserver localhost:50505 ./myprogram '"hello world"'

or

    gdbserver localhost:50505 ./myprogram "hello\ world"

instead of just

    gdbserver localhost:50505 ./myprogram "hello world"

* when using the '--no-startup-with-shell' arg for gdbserver, no extra escaping
needs to be done by the user, i.e. the following should work and result in a
single "hello world" arg being passed to the inferior:

    gdbserver --no-startup-with-shell localhost:50505 ./myprogram "hello world"


What do you think? Any thoughts or better ideas how to deal with the situation
are highly appreciated.


[1] https://sourceware.org/gdb/onlinedocs/gdb/Starting.html

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

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

[nikita6 at bk dot ru]

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

--- Comment #2 from Nikita Strygin <nikita6 at bk dot ru> ---
I think your solution sounds reasonable: it will fix the
'--no-startup-with-shell' with spaces and keep the compatibility for
'--startup-with-shell'

I think it might also be beneficial to update the docs to make clear what is
the difference. Currently it only says that 'startup-with-shell off' might be
useful when shell crashes for some reason.

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

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

[m.weghorn at posteo dot de]

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

--- Comment #3 from Michael Weghorn <m.weghorn at posteo dot de> ---
@Simon: Do you think the approach mentioned in comment 1 is reasonable?

If so, I'll work on implementing that (presumably sometime next week).

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

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

[simon.marchi at polymtl dot ca]

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

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #4 from Simon Marchi <simon.marchi at polymtl dot ca> ---
I don't really know what's best here.  I just tried your different examples to
get a feel of the problem, but I don't have a definite answer.  It seems
difficult to reconcile all use cases.

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.

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

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

[m.weghorn at posteo dot de]

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.

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

[simon.marchi at polymtl dot ca]

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

--- Comment #6 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(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 <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.

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
> <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.

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=data-directory -batch -ex r --args ./a.out
'$SHELL'
[0] /home/smarchi/build/binutils-gdb/gdb/a.out
[1] $SHELL

$ ./a.out "> out"       
[0] ./a.out
[1] > out
$ ./gdb -nx -q --data-directory=data-directory -batch -ex r --args ./a.out '>
out' 
[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 invokation),
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.
> 
> 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.

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.
> 
> 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 11.1
(IIUC).  And it's what is in master today.  We could always revert to the old
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 different
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.

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

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

[m.weghorn at posteo dot de]

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

--- Comment #7 from Michael Weghorn <m.weghorn at posteo dot de> ---
> 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
> 11.1 (IIUC).  And it's what is in master today.  We could always revert to
> the old 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
> different 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.

Thanks a lot for you input.
Unless I completely misunderstand something, I'd read that as being in favour
of what I tried to describe as option **2** in comment 5, though, right? (not
option 1)

If so, I'll try to come up with patches to implement that.

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

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

[simark at simark dot ca]

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

--- Comment #8 from Simon Marchi <simark at simark dot ca> ---
> Thanks a lot for you input.
> Unless I completely misunderstand something, I'd read that as being in
> favour of what I tried to describe as option **2** in comment 5, though,
> right? (not option 1)
> 
> If so, I'll try to come up with patches to implement that.

That's right.  Thanks!

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

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

[m.weghorn at posteo dot de]

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

--- Comment #9 from Michael Weghorn <m.weghorn at posteo dot de> ---
(In reply to Michael Weghorn from comment #7)
> If so, I'll try to come up with patches to implement that.

First version of the patches just sent to the mailing list:
https://sourceware.org/pipermail/gdb-patches/2021-October/182723.html

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

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
Latest state:
https://inbox.sourceware.org/gdb-patches/cover.1704809585.git.aburgess@redhat.com

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