[mingw gdb/mi] Separating debuggee output from MI

[mingw gdb/mi] Separating debuggee output from MI

[Noobody]

I'm currently writing a gdb frontend using the GDB/MI interface, but I have
been experiencing difficulties with differentiating between output by the
debuggee and output from gdb itself.

The documentation mentions target-stream-output, which is prefixed with "@",
but it seems it is not actually being used. Instead, target output appears
interleaved with gdb output.

This can cause various problems, so I would like to be able to safely 
separate
target output/input from gdb output/input. Searching for a bit revealed that
this is quite a common problem when writing gdb frontends on windows due to
various limitations of the OS, but I was unable to find a good solution.

I implemented a workaround to this which seems to work, however I am not 
quite
sure whether it is safe to use.

What I'm doing right now is start the debuggee process in suspended mode 
from
the frontend (with CreateProcess and CREATE_SUSPENDED flag), create the gdb
process separately, attach it to the suspended process and then resume it
with ResumeThread (assuming a single-threaded program).

Something like this:

/* Start debug process */
CreateProcess(...)

/* Start gdb */
  gdb.exe -i mi
 >> -target-attach pid
<< *stopped
 >> -exec-continue
<< *running,thread-id="all"

/* Resume suspended process */
ResumeThread(...)

This seems to work, as I now have the debuggee input/output and the gdb
input/output in separate pipes. However, I have not had the chance to 
test this
any further, so I'm wondering - could this setup could cause any problems?
Especially the fact that I'm doing -exec-continue on a suspended process 
seems
like asking for trouble.

Thanks!
Benedikt Bitterli

Re: [mingw gdb/mi] Separating debuggee output from MI

[Eran Ifrah]

Hi,

I also faced this problem while ago when implementing it, what did the
trick for me was to execute 'set new-console on' after starting gdb
but before executing the target
so the sequence should be something like this:

>gdb <executable>
>set new-console on
>.. other initialization commands ...
>run <args>


By running this command, gdb will create a new console for the debugee output.
i.e. all the redirected IO that you capture in your frontend will
always be gdb's output.

Note: this command does not work under Linux / Mac. To achieve this on
*NIX, you need to pass
--tty=/dev/pts/XX to gdb for achieving the same effect.

Also, here is a complete reference for codelite's GDB MI implementation:
http://codelite.svn.sourceforge.net/viewvc/codelite/trunk/Debugger/debuggergdb.cpp?revision=5439&view=markup

Look at around line 1025 in function : DoInitializeGdb()


HTH

On Tue, May 15, 2012 at 9:20 AM, Noobody <mail@noobody.org> wrote:
> I'm currently writing a gdb frontend using the GDB/MI interface, but I have
> been experiencing difficulties with differentiating between output by the
> debuggee and output from gdb itself.
>
> The documentation mentions target-stream-output, which is prefixed with "@",
> but it seems it is not actually being used. Instead, target output appears
> interleaved with gdb output.
>
> This can cause various problems, so I would like to be able to safely
> separate
> target output/input from gdb output/input. Searching for a bit revealed that
> this is quite a common problem when writing gdb frontends on windows due to
> various limitations of the OS, but I was unable to find a good solution.
>
> I implemented a workaround to this which seems to work, however I am not
> quite
> sure whether it is safe to use.
>
> What I'm doing right now is start the debuggee process in suspended mode
> from
> the frontend (with CreateProcess and CREATE_SUSPENDED flag), create the gdb
> process separately, attach it to the suspended process and then resume it
> with ResumeThread (assuming a single-threaded program).
>
> Something like this:
>
> /* Start debug process */
> CreateProcess(...)
>
> /* Start gdb */
>  gdb.exe -i mi
>>> -target-attach pid
> << *stopped
>>> -exec-continue
> << *running,thread-id="all"
>
> /* Resume suspended process */
> ResumeThread(...)
>
> This seems to work, as I now have the debuggee input/output and the gdb
> input/output in separate pipes. However, I have not had the chance to test
> this
> any further, so I'm wondering - could this setup could cause any problems?
> Especially the fact that I'm doing -exec-continue on a suspended process
> seems
> like asking for trouble.
>
> Thanks!
> Benedikt Bitterli



-- 
Eran Ifrah
Author of the cross platform, open source C++ IDE: http://www.codelite.org
YTubePlayer http://www.ytubeplayer.com

Re: [mingw gdb/mi] Separating debuggee output from MI

[asmwarrior]

On 2012-5-15 14:44, Eran Ifrah wrote:
> Hi,
>
> I also faced this problem while ago when implementing it, what did the
> trick for me was to execute 'set new-console on' after starting gdb
> but before executing the target
> so the sequence should be something like this:
>
>> gdb<executable>
>> set new-console on
>> .. other initialization commands ...
>> run<args>
>
>
> By running this command, gdb will create a new console for the debugee output.
> i.e. all the redirected IO that you capture in your frontend will
> always be gdb's output.
>
> Note: this command does not work under Linux / Mac. To achieve this on
> *NIX, you need to pass
> --tty=/dev/pts/XX to gdb for achieving the same effect.
>
> Also, here is a complete reference for codelite's GDB MI implementation:
> http://codelite.svn.sourceforge.net/viewvc/codelite/trunk/Debugger/debuggergdb.cpp?revision=5439&view=markup
>
> Look at around line 1025 in function : DoInitializeGdb()
>


Hi, eran, that's was a good solution.

I have such issue several days ago when I used gdb-mi plugin for Codeblocks.

I will ask OBF (the gdb-mi plugin maintainer) to follow your steps.

Thanks.

BTW: I remember once I have such issue, I looked up this in the GDB documents, but no information about this Windows specific issue, So can some one enhanced this in the gdb documents?

Yuanhui Zhang
ollydbg(Codeblocks forum ID)

Re: [mingw gdb/mi] Separating debuggee output from MI

[Noobody]

 >By running this command, gdb will create a new console for the debugee 
output.
 >i.e. all the redirected IO that you capture in your frontend will 
always be gdb's output.

Hi,

Thanks for the tip!
I am aware of this option, but I would prefer to be able to handle 
input/output
from the debugger itself. The problem is that the Windows console is not
exactly very convenient when it comes to handling standard operations 
such as
copying, pasting, window resizing or similar. Also, keeping all the info and
controls in one window instead of two when debugging would be 
preferrable in my
opinion.

As such, I've been looking for methods to get hold of the debuggees output
directly (which I probably should have mentioned in the first mail).

The method I have now seems to work fine, but I just know too little of 
gdb's
internals to be able to tell whether this could cause problems in the 
future.

RE: [mingw gdb/mi] Separating debuggee output from MI

[Marc Khouzam]

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Noobody
> Sent: Tuesday, May 15, 2012 8:13 AM
> To: eran.ifrah@gmail.com
> Cc: gdb@sourceware.org
> Subject: Re: [mingw gdb/mi] Separating debuggee output from MI
> 
>  >By running this command, gdb will create a new console for 
> the debugee 
> output.
>  >i.e. all the redirected IO that you capture in your frontend will 
> always be gdb's output.
> 
> Hi,
> 
> Thanks for the tip!
> I am aware of this option, but I would prefer to be able to handle 
> input/output
> from the debugger itself. The problem is that the Windows 
> console is not
> exactly very convenient when it comes to handling standard operations 
> such as
> copying, pasting, window resizing or similar. Also, keeping 
> all the info and
> controls in one window instead of two when debugging would be 
> preferrable in my
> opinion.
> 
> As such, I've been looking for methods to get hold of the 
> debuggees output
> directly (which I probably should have mentioned in the first mail).
> 
> The method I have now seems to work fine, but I just know too 
> little of 
> gdb's
> internals to be able to tell whether this could cause problems in the 
> future.

This is a problem that Eclipse users on Windows have been facing for 
a while.  We got multiple Eclipse bug reports about it.  We usually
tell our users to use "set new-console on" as a workaroud.
Your proposed workaround is interesting but I still see it as a
workaround.  It would be great if GDB had a integrated fix for this.

Marc