Re: [PATCH 0/6] Add vDefaultInferiorFd feature

[Andrew Burgess <aburgess@redhat.com>]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Alexandra" == Alexandra Petlanova Hajkova <ahajkova@redhat.com> writes:
>
>>  Another approach might be to have a different way to specify the
>>  connection fd to the remote, like a command-line option naming the fd to
>>  use for RSP traffic.
>
> Alexandra> Are you imagining something like "target remote | gdbserver --once RSP_FD ...." ?
> Alexandra> And GDB would replace RSP_FD with the actual file descriptor to use?
>
> Yeah.

There is one problem I see with this approach, maybe a bit of an edge
case, but, what if the application wanted to use the text RSP_FD
elsewhere in it's command line.  For example, a user does:

  (gdb) target remote | gdbserver --once RSP_FD /tmp/myprog

And everything is great, GDB replaces RSP_FD with the descriptor to use
for RSP traffic, and that's fine.

Or a user does:

  (gdb) target remote | gdbserver --once /tmp/myprog

And GDB doesn't spot RSP_FD, so doesn't redirect the RSP traffic, and
just continues to use stdin/stdout as it does right now.

But what about the poor user who needs to do this:

  (gdb) target remote | gdbserver --once /tmp/myprog RSP_FD

that is the 'RSP_FD' is an actual argument string to pass to 'myprog'!
Unlikely maybe, but not impossible.  Anything that requires GDB to
understand the command that appears after the `|` suffers from the
possibility that GDB might get it wrong.

>
> Alexandra> avoids adding a new packet and the whole FD switching business. But adding the new 
> Alexandra> packet approach makes it easier for the users. It's possible to run GDB to then run
> Alexandra>  Valgrind from inside by using simply
>
> Alexandra> target extended-remote | vgdb --multi
>
> Alexandra> I hope this command will be replaced with an even simpler " target valgrind" at
> Alexandra> some point.
>
> Part of the idea would be to hide the new file descriptor handling
> behind the "target valgrind" facade.  That is, the implementation of
> "target valgrind" would handle setting up the command line arguments to
> vgdb.

Even writing a Python wrapper doesn't really solve the above problem, it
just shifts it from GDB into the Python code.

And (I think) ideally we wouldn't rely on users having to write a Python
wrapper in order to use this feature with their own tools, so it would
be nice if this feature was usable from pure GDB.

Maybe it's just enough to add an on/off control setting, and have GDB
announce when it's performed the command line replacements.  Then
(hopefully) users will know that if they don't want this feature they
could turn this off...

Just my thoughts.

Thanks,
Andrew