This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 0/4] GDBServer: introduce a dedicated stderr stream
- From: Pedro Alves <palves at redhat dot com>
- To: Cleber Rosa <crosa at redhat dot com>, gdb-patches at sourceware dot org
- Cc: areis at redhat dot com, Sergio Durigan Junior <sergiodj at redhat dot com>
- Date: Sat, 21 Mar 2015 15:05:00 +0000
- Subject: Re: [PATCH 0/4] GDBServer: introduce a dedicated stderr stream
- Authentication-results: sourceware.org; auth=none
- References: <1426905265-8495-1-git-send-email-crosa at redhat dot 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.