Re: [PATCH 00/16] Inferior argument (inc for remote targets) changes

[Andrew Burgess <aburgess@redhat.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrew Burgess <aburgess@redhat.com>
>> Cc: Andrew Burgess <aburgess@redhat.com>, Michael Weghorn <m.weghorn@posteo.de>
>> Date: Tue,  9 Jan 2024 14:26:23 +0000
>> 
>> This series relates to bug PR gdb/28392.  For background, check out
>> this series:
>> 
>>   https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de
>> 
>> which is a previous attempt to address this bug.
>> 
>> It might also be worth reading:
>> 
>>   https://inbox.sourceware.org/gdb-patches/2b98ca58e47638b4760d86bd6e1fa9a9a79fa2ad.1695817255.git.aburgess@redhat.com
>> 
>> which is a previous series of mine which covers some of the work from
>> the original patch series.
>> 
>> This series does include many ideas taken from the original patch
>> series (thanks for Michael (original series author) for his work).  I
>> think this iteration does include some additional fixes beyond the
>> original series, also there are more tests and documentation changes
>> in this version.
>> 
>> There is one small problem: patch #1 is within libiberty.  I have
>> posted this to the gcc list here:
>> 
>>   https://inbox.sourceware.org/gcc-patches/24a8d878590403540bc9b579ba58805985a4d2f7.1701881419.git.aburgess@redhat.com/
>> 
>> However, GCC is currently in stage 4 of its release cycle, so I'm not
>> expecting to see that patch merged before April, I've expanded on this
>> more within the patch #1 email.
>> 
>> Still, there's plenty here to comment on, and I figure between now and
>> April I can address any feedback that's given.
>
> Thanks.  It is hard to follow all these changes especially as they are
> broken into so many pieces, but I cannot avoid asking: what does this
> mean for the quoting/escaping of arguments by GDB as a native debugger
> on MS-Windows?
>
> For starters, AFAIK on Windows there's no such thing as "startup with
> shell", as the inferior is never invoked via the Windows shell.  So
> what does this feature mean and how (and whether) will it work in a
> native GDB running on Windows debugging Windows programs?  Likewise
> with the --no-escape-args command-line option?
>
> And this text:
>
>> When starting GDB it is possible to set an inferior argument that
>> contains a newline, for example:
>> 
>>   shell> gdb --args my.app "abc
>>   > def"
>>   ...
>>   (gdb) show args
>>   Argument list to give program being debugged when it is started is "abc'
>>   'def".
>> 
>> However, once GDB is started, the only way to install an argument
>> containing a newline is to use the Python API.
>> 
>> This commit changes that.
>> 
>> After this commit 'set args' as well as 'run', 'start', and 'starti',
>> will now accept multi-line inferior arguments, e.g.:
>> 
>>   (gdb) set args "abc
>>   > def"
>>   (gdb) show args
>>   Argument list to give program being debugged when it is started is ""abc
>>   def"".
>> 
>> And also:
>> 
>>   (gdb) run "abc
>>   > def"
>>   ... etc ...
>
> seems to say that quoting arguments can cause the inferior's
> command-line arguments to include a newline, but AFAIK there's no way
> to make that work on MS-Windows.  If that is true, we should at least
> document the lack of support for this on Windows.
>
> Thanks, and apologies in advance if my questions make no sense.

The question makes perfect sense.

My hope is that the situation on Windows is no better or worse than it
ever was.

I'm reluctant to start writing documentation saying feature X does or
does not work on Windows and why though as I don't have access to a
Windows machine on which I can test any of this.

Specifically on the question of passing a newline within an argument, I
guess (having taken a quick peek at the window-nat.c file) that
embedding a newline within the argument string would cause problems?

I believe it's already possible today to inject newline characters via
the Python API.  Maybe the window-nat.c code should be checking for
invalid characters and throw an error if the user tries to start an
inferior.  I guess the other option would be to check the arguments at
the moment the user sets them ... but this isn't going to work if the
user sets the arguments before connecting to a remote target, so I
suspect it makes more sense to detect invalid argument characters just
prior to starting the inferior and giving an error at that point.

I agree that platform specific limitations should be documented.  I'm
willing to help however I can to get that done.  But I'm a little
uncomfortable trying to document something I can't test.  I'll see if I
can source a Windows laptop, maybe I can build/test in that setup.

Thanks,
Andrew