Re: [PATCH 0/4] GDBServer: introduce a dedicated stderr stream

[Pedro Alves <palves@redhat.com>]

On 03/21/2015 02:34 AM, Cleber Rosa wrote:
> This  patch series add command line options and monitor commands that
> will redirect all of the gdbserver's own output (always sent to stderr)
> to a separate file. This feature makes it possible to distinguish between
> the inferior process stderr and gdbserver's own stderr.

A specific FILE* is a fragile approach; libraries that gdbserver loads
may well print to stdout/stderr or write to file descriptors 1 or
2 directly, for example.  If we're doing this, redirection is best done
at the lower OS file descriptor layer, not at C-runtime stdio (stdout/stderr)
layer, with e.g., dup/dup2.

And, gdbserver itself may print to stdout/stderr _before_ the redirection
command-line option is processed.  Thus it's safer/better to just start gdbserver
with its input/output redirected already.  Of course, then because new
inferiors inherit the input/output from gdbserver, we'd need a way to
start the inferior with input/output redirected somewhere instead.

When native debugging, we can already do exactly that: we can
tell gdb to starts inferior with input/output redirected, using the
"set inferior-tty" command.  I'd be very desirable to be able to do that
with gdbserver as well, in the context of local/remote parity too.  That makes
it possible to have one single gdbserver start multiple programs on separate
ttys, for example.

And I think that would cover your use case too.
You'd start gdbserver with input/output redirected to a pipe, like you
seem to already do (for example), and pass it --inferior-tty=`tty` so
that new inferiors start with input/output connected to that tty.

What do you think?

The code to do this in gdb is in fork-child.c and inflow.c.  Ideally
we'd share it with gdbserver...  Sergio has been on and off working
on exactly sharing that code, for startup-with-shell.

Thanks,
Pedro Alves