From: Marc Khouzam <marc.khouzam@ericsson.com>
To: "'lgustavo@codesourcery.com'" <lgustavo@codesourcery.com>,
"'Adrian Sendroiu'" <adrian.sendroiu@freescale.com>,
"'gdb@sourceware.org'" <gdb@sourceware.org>
Subject: RE: Output stream for monitor commands
Date: Thu, 03 Jul 2014 13:48:00 -0000 [thread overview]
Message-ID: <E59706EF8DB1D147B15BECA3322E4BDC1C696950@eusaamb103.ericsson.se> (raw)
In-Reply-To: <53B5349C.3020005@codesourcery.com>
> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Luis Machado
> Sent: Thursday, July 03, 2014 6:47 AM
> To: Adrian Sendroiu; gdb@sourceware.org
> Subject: Re: Output stream for monitor commands
>
> On 07/03/2014 11:22 AM, Adrian Sendroiu wrote:
> > Hello,
> >
> > When running gdb inside the Eclipse environment, I noticed that the
> output of the monitor commands goes to the "gdb traces" window, as
> opposed to all others that go to the "gdb" window. This happens because the
> qRcmd packet's response uses the gdb_stdtarg stream while the others use
> gdb_stdout.
[...]
> There seems to be an ongoing discussion at
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=208950.
Yes, we are struggling with how to handle the target-stream (prefixed with @).
Currently, from what we understand, GDB does not differentiate between
output from the target (like the result to a monitor command) and output
from the inferior. This was directing us to print all target-stream output
to the eclipse gdb console, just like when you run gdb from the command-line.
However, this is apparently quite confusing when you have to also handle
input from the inferior and from gdb. (This may be a non-stop issue only
and I'm waiting on an answer to that).
The solution that is currently being proposed is to have an inferior
console in eclipse in which we would print target-stream output and handle
input to the inferior, and pay special attention to results of monitor commands
which would be sent to the gdb console instead. I'm not a fan of this solution
which specifically focuses on the monitor command as an exception.
If anyone has some information on how the target-stream (@) is meant to
be used by a front-end, it may clarify our discussion.
Thanks
Marc
prev parent reply other threads:[~2014-07-03 13:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 10:22 Adrian Sendroiu
2014-07-03 10:47 ` Luis Machado
2014-07-03 13:48 ` Marc Khouzam [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E59706EF8DB1D147B15BECA3322E4BDC1C696950@eusaamb103.ericsson.se \
--to=marc.khouzam@ericsson.com \
--cc=adrian.sendroiu@freescale.com \
--cc=gdb@sourceware.org \
--cc=lgustavo@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox