This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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:

Look at around line 1025 in function : DoInitializeGdb()


On Tue, May 15, 2012 at 9:20 AM, Noobody <> 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:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]