This is the mail archive of the
mailing list for the GDB project.
Re: [mingw gdb/mi] Separating debuggee output from MI
- From: Eran Ifrah <eran dot ifrah at gmail dot com>
- To: gdb at sourceware dot org
- Date: Tue, 15 May 2012 09:44:01 +0300
- Subject: Re: [mingw gdb/mi] Separating debuggee output from MI
- References: <4FB1F5B5.firstname.lastname@example.org>
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:
>set new-console on
>.. other initialization commands ...
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:
Look at around line 1025 in function : DoInitializeGdb()
On Tue, May 15, 2012 at 9:20 AM, Noobody <email@example.com> 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
> 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
> sure whether it is safe to use.
> What I'm doing right now is start the debuggee process in suspended mode
> 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 */
> /* Start gdb */
> ?gdb.exe -i mi
>>> -target-attach pid
> << *stopped
> << *running,thread-id="all"
> /* Resume suspended process */
> 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
> 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
> like asking for trouble.
> Benedikt Bitterli
Author of the cross platform, open source C++ IDE: http://www.codelite.org