This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Target stderr not displayed thru MI
- From: Daniel Jacobowitz <drow at false dot org>
- To: Denis PILAT <denis dot pilat at st dot com>, Nick Roberts <nickrob at snap dot net dot nz>, gdb-patches at sources dot redhat dot com
- Date: Thu, 1 Dec 2005 09:32:18 -0500
- Subject: Re: [PATCH] Target stderr not displayed thru MI
- References: <17293.36697.854192.691800@kahikatea.snap.net.nz> <438DA1DE.2020406@st.com> <17294.2894.345752.773239@kahikatea.snap.net.nz> <438F011F.7050403@st.com> <20051201140436.GA31759@white>
On Thu, Dec 01, 2005 at 09:04:36AM -0500, Bob Rossi wrote:
> > I attach a new patch in that sense. It does not include the documentation
> > patch about MI new stream but it's just to give you an idea.
> > Any comment ?
>
> > + /* MI 1 and 2 target error stream use the same steam prefix "@" in oder
> > + to ensure backward compatibility with old frondtend, MI 3 uses
> > + a new prefix "#" */
> > + if (mi_version (uiout) > 2)
> > + mi->targerr = mi_console_file_new (raw_stdout, "#", '"');
> > + else
> > + mi->targerr = mi_console_file_new (raw_stdout, "@", '"');
> > +
> > mi->event_channel = mi_console_file_new (raw_stdout, "=", 0);
>
> We have a lot of people that are confused about the target-stream-output
> and it was recently brought up that maybe this wasn't used and should be
> removed.
>
> http://sources.redhat.com/ml/gdb/2005-11/msg00391.html
>
> However, you seem to be using it, and want to add another stream-output,
> probably called something like target-stream-stderr-output.
>
> I haven't seen MI use the target-stream-output yet. What is your
> configuration that makes this happen? Is it still useful to you?
> If so, it would be nice if we could improve the doco a bit, to let users
> know when this would be useful for them.
It's used for any (most?) remote or simulator targets that can provide
output. I'm sorry if I was not adequately clear about that. The ST
folks appear to have their own proprietary remote target, which also
generates these packets.
Nick, what's your reasoning for separating this from the stdout data?
When we put the inferior onto its own TTY, we don't get stdout and
stderr separated, either.
--
Daniel Jacobowitz
CodeSourcery, LLC