Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Output stream for monitor commands
@ 2014-07-03 10:22 Adrian Sendroiu
  2014-07-03 10:47 ` Luis Machado
  0 siblings, 1 reply; 3+ messages in thread
From: Adrian Sendroiu @ 2014-07-03 10:22 UTC (permalink / raw)
  To: gdb

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.

This might come as an issue, because, from the user's point of view, "monitor" is just another command, and it would be expected to see its output together with the output of the other commands. Do you think it's right to assume so? Do you have any suggestions about how this could be fixed? I was thinking that maybe I could implement a gdb command to redirect gdb_stdtarg to gdb_stdout, so that the current behaviour is also preserved.

Thanks,
Adrian


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Output stream for monitor commands
  2014-07-03 10:22 Output stream for monitor commands Adrian Sendroiu
@ 2014-07-03 10:47 ` Luis Machado
  2014-07-03 13:48   ` Marc Khouzam
  0 siblings, 1 reply; 3+ messages in thread
From: Luis Machado @ 2014-07-03 10:47 UTC (permalink / raw)
  To: Adrian Sendroiu, gdb

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.
>
> This might come as an issue, because, from the user's point of view, "monitor" is just another command, and it would be expected to see its output together with the output of the other commands. Do you think it's right to assume so? Do you have any suggestions about how this could be fixed? I was thinking that maybe I could implement a gdb command to redirect gdb_stdtarg to gdb_stdout, so that the current behaviour is also preserved.
>
> Thanks,
> Adrian
>
>

There seems to be an ongoing discussion at 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=208950.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: Output stream for monitor commands
  2014-07-03 10:47 ` Luis Machado
@ 2014-07-03 13:48   ` Marc Khouzam
  0 siblings, 0 replies; 3+ messages in thread
From: Marc Khouzam @ 2014-07-03 13:48 UTC (permalink / raw)
  To: 'lgustavo@codesourcery.com', 'Adrian Sendroiu',
	'gdb@sourceware.org'

> -----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




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-07-03 13:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-03 10:22 Output stream for monitor commands Adrian Sendroiu
2014-07-03 10:47 ` Luis Machado
2014-07-03 13:48   ` Marc Khouzam

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox