Debugger plugin: GDB MI interface features and issues

[ollydbg]

I have tried OBF's new debugger plugin which use GDB-MI interface.
GIT source address

Code

https://github.com/obfuscated/cb_gdbmi

EDIT 2013-05-09 : the current status of this plugin is Here

I build it under MinGW 4.6.x, and here is what I changed:
It looks like int32_t and int64_t is not defined.

So, I add such code snippet:(in src\cmd_queue.h)

Code

typedef int int32_t;
typedef long int int64_t;

I adjust some include search path, I think the whole src folder can be put under:
cb_trunk\src\plugins
So that only relative include search path is needed. (Just like other plugin sources), also using this way, the pack.bat maybe are not needed.

Anyway, this plugin works GREAT!!!

[MortenMacFly]

So, I add such code snippet:(in src\cmd_queue.h)

Code

typedef int int32_t;
typedef long int int64_t;

You should better include <cstdint> (stdint.h).

In fact, I never tried - can it run in parallel to the existing debugger? (I mean do I need to disable the other plugin?)

[ollydbg]

So, I add such code snippet:(in src\cmd_queue.h)

Code

typedef int int32_t;
typedef long int int64_t;

You should better include <cstdint> (stdint.h).

OK, I will try it, thanks.

In fact, I never tried - can it run in parallel to the existing debugger? (I mean do I need to disable the other plugin?)

Yes, you can either select the existing debugger or the gdb-mi debugger in the "Compiler setting“ dialog. There is a new tree item in the "debugger setting" dialog which is for configuring gdb-mi feature. Many UI parts I believe are shared together.

[oBFusCATed]

@ollydbg: Use <cstdint> as Morten said
@morten: Yes you can use both and it should work, that is the idea of the api redesign in fact. Also if you find bugs please report them.


@admins: Can you move the topic in the plugins section?

[Jenna]

@admins: Can you move the topic in the plugins section?

Done !

[ollydbg]

One tiny feature request is:
Could you add the macro replacement in the "GDB path" and "initial command" edit control. This is already implemented in trunk. Thanks.

[MortenMacFly]

@morten: Yes you can use both and it should work, that is the idea of the api redesign in fact. Also if you find bugs please report them.

Nice to hear. If it seems to work already (maybe not perfect) is there any particular reason not t move it into trunk now? (We don't necessarily need to add it to the build system until you tell though...).

[Pecan]

I have tried OBF's new debugger plugin which use GDB-MI interface.
SVN address

Code

svn://cmpt.benbmp.org/cb_gdb_mi/debbugger_gdbmi

Anyway, this plugin works GREAT!!!

I can debug small projects with it, but it crashes while it is loading DLL's on my system when I attempt to debug CB with it.

Have you tried to debug CB with it? Did it work?
What system are you running? What version of GCC and GDB are you using?

[oBFusCATed]

Could you add the macro replacement in the "GDB path" and "initial command" edit control. This is already implemented in trunk. Thanks.

Yes, I will, I think Pecan showed me a patch somewhere about this, but I've not time to apply it.

Morten: I'm thinking of adding a src/plugin/debuggers/ directory and to put all debugger plugins there.

[ollydbg]

I have tried OBF's new debugger plugin which use GDB-MI interface.
SVN address

Code

svn://cmpt.benbmp.org/cb_gdb_mi/debbugger_gdbmi

Anyway, this plugin works GREAT!!!

I can debug small projects with it, but it crashes while it is loading DLL's on my system when I attempt to debug CB with it.

Everything works fine here. 

Have you tried to debug CB with it? Did it work?

I can debug CB, and I can debug a wxAPP which link to wx debug library (In this case, I can debug to wxWidget's source code)

What system are you running? What version of GCC and GDB are you using?

WindowsXP, I use GCC 4.6.3 from xunxun(http://pcxprj.googlecode.com/files/MinGW64CRT_gcc4.6.3release_sse2static_win32.7z)
The GDB is build myself using GCC 4.6.3, it is GDB CVS code with some of my patches, See:
http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000  (This page contains more details)
The GDB is build with python enabled (link to python DLL, so you need to download the python 2.7.x official release).

Oh, I see the page [OT] unofficial MinGW GDB gdb with python released is a 2012-02-16 release, I'm currently use 2012-04-20 CVS build, but I don't think there are much difference. If you want/ask to try my new build(2012-04-20), I can make/upload a new release. 

Could you add the macro replacement in the "GDB path" and "initial command" edit control. This is already implemented in trunk. Thanks.

Yes, I will.

Nice to put gdb/mi debugger plugin in the trunk!

[MortenMacFly]

Yes, I will, I think Pecan showed me a patch somewhere about this, but I've not time to apply it.
[...]
Morten: I'm thinking of adding a src/plugin/debuggers/ directory and to put all debugger plugins there.

See - in trunk, the community and other devs can help.

[Pecan]

Everything works fine here.  

Would you post a debugger log of GDB/MI starting up so I can compare it with mine to see why GDB/MI insists on loading a bazillion DLL's while loading CB and then craps out on about the 40th?
 

[ollydbg]

Everything works fine here.  

Would you post a debugger log of GDB/MI starting up so I can compare it with mine to see why GDB/MI insists on loading a bazillion DLL's while loading CB and then craps out on about the 40th?
 

Here it is.
The log file contains something below:
The debugee C::B start up, and load a project, then meet a BP(in a DLL).

EDIT: It looks like some of the log message of debugee is re-directed and show in the debugger_mi's log. That's interesting, you can see many messages like:

Code

...
[debug]unparsable_output==>WindowsXPLookNFeel: loaded
[debug]unparsable_output==>Abbreviations plugin activated
[debug]unparsable_output==>Source code formatter (AStyle) plugin activated
[debug]unparsable_output==>Autosave plugin activated
[debug]unparsable_output==>Class wizard plugin activated
[debug]unparsable_output==>Code completion plugin activated
[debug]unparsable_output==>Added compiler "GNU GCC Compiler"
[debug]unparsable_output==>Updating class browser...
[debug]unparsable_output==>Class browser updated.
[debug]unparsable_output==>Added compiler "Microsoft Visual C++ Toolkit 2003"
[debug]unparsable_output==>Added compiler "Microsoft Visual C++ 2005/2008"
[debug]unparsable_output==>Added compiler "Microsoft Visual C++ 2010"
[debug]unparsable_output==>Added compiler "Borland C++ Compiler (5.5, 5.82)"
[debug]unparsable_output==>Added compiler "Digital Mars Compiler"
[debug]unparsable_output==>Added compiler "OpenWatcom (W32) Compiler"
[debug]unparsable_output==>Added compiler "GNU GCC Compiler for MSP430"
...

[ollydbg]

EDIT: It looks like some of the log message of debugee is re-directed and show in the debugger_mi's log. That's interesting, you can see many messages like:

I found a bug, the debugee's start-up arguments does not set/send correctly.

It should use some command:
"-exec-arguments"
before
"-exec-run"

EDIT: This is the patch to add args:

Code

--- plugin.cpp	Thu Jan 15 17:14:12 1970
+++ plugin.cpp	Thu Jan 15 17:14:12 1970
@@ -570,11 +570,12 @@
         return 3;
     }
 
     // is gdb accessible, i.e. can we find it?
     wxString debugger = GetActiveConfigEx().GetDebuggerExecutable();
-    wxString debuggee, working_dir;
+    wxString debuggee, working_dir;
+    wxString args = target->GetExecutionParameters();
     if (!GetDebuggee(debuggee, working_dir, target))
     {
         m_hasStartUpError = true;
         return 6;
     }
@@ -588,11 +589,11 @@
     {
         wxSetEnv(CB_LIBRARY_ENVVAR, newLibPath);
         DebugLog(CB_LIBRARY_ENVVAR _T("=") + newLibPath);
     }
 
-    int res = LaunchDebugger(debugger, debuggee, working_dir, 0, console, start_type);
+    int res = LaunchDebugger(debugger, debuggee, args, working_dir, 0, console, start_type);
     if (res != 0)
     {
         m_hasStartUpError = true;
         return res;
     }
@@ -604,11 +605,11 @@
     if (oldLibPath != newLibPath)
         wxSetEnv(CB_LIBRARY_ENVVAR, oldLibPath);
     return 0;
 }
 
-int Debugger_GDB_MI::LaunchDebugger(wxString const &debugger, wxString const &debuggee,
+int Debugger_GDB_MI::LaunchDebugger(wxString const &debugger, wxString const &debuggee, wxString const &args,
                                     wxString const &working_dir, int pid, bool console,
                                     StartType start_type)
 {
     m_current_frame.Reset();
     if(debugger.IsEmpty())
@@ -642,11 +643,14 @@
         return ret;
 
     m_executor.Stopped(true);
 //    m_executor.Execute(_T("-enable-timings"));
     CommitBreakpoints(true);
-    CommitWatches();
+    CommitWatches();
+
+    //Set program arguments -exec-arguments
+    m_actions.Add(new dbg_mi::SimpleAction(wxT("-exec-arguments ") + args));
 
     if(console)
     {
         wxString console_tty;
         m_console_pid = RunNixConsole(console_tty);
@@ -1263,12 +1267,12 @@
 
     long number;
     if (!pid.ToLong(&number))
         return;
 
-    LaunchDebugger(GetActiveConfigEx().GetDebuggerExecutable(), wxEmptyString, wxEmptyString,
-                   number, false, StartTypeRun);
+    LaunchDebugger(GetActiveConfigEx().GetDebuggerExecutable(), wxEmptyString, wxEmptyString,
+                   wxEmptyString, number, false, StartTypeRun);
     m_executor.SetAttachedPID(number);
 }
 
 void Debugger_GDB_MI::DetachFromProcess()
 {
--- plugin.h	Thu Jan 15 17:14:12 1970
+++ plugin.h	Thu Jan 15 17:14:12 1970
@@ -159,12 +159,12 @@
         void OnTimer(wxTimerEvent& event);
         void OnIdle(wxIdleEvent& event);
 
         void OnMenuInfoCommandStream(wxCommandEvent& event);
 
-        int LaunchDebugger(wxString const &debugger, wxString const &debuggee, wxString const &working_dir,
-                           int pid, bool console, StartType start_type);
+        int LaunchDebugger(wxString const &debugger, wxString const &debuggee, wxString const &args,
+                           wxString const &working_dir, int pid, bool console, StartType start_type);
 
     private:
         void AddStringCommand(wxString const &command);
         void DoSendCommand(const wxString& cmd);
         void RunQueue();

PS: I even make a noise in the GDB maillist. 
http://sourceware.org/ml/gdb/2012-04/msg00180.html

[Pecan]

Would you post a debugger log of GDB/MI starting up so I can compare it with mine to see why GDB/MI insists on loading a bazillion DLL's while loading CB and then craps out on about the 40th?
 

Here it is.
The log file contains something below:
The debugee C::B start up, and load a project, then meet a BP(in a DLL).

How much memory does your system have?

[ollydbg]

4G, but I don't think that's the crash reason.  gdb takes 180M.

[oBFusCATed]

Ollydbg: I've committed your patch, thank you.

[ollydbg]

So, I add such code snippet:(in src\cmd_queue.h)

Code

typedef int int32_t;
typedef long int int64_t;

You should better include <cstdint> (stdint.h).

@OBF, can you add this?
In my PCXMinGW 4.6.3, if I wrote:

Code

#include <cstdint>

I will have a build error

Code

In file included from e:\code\gcc\pcxmingw463\bin\../lib/gcc/i686-w64-mingw32/4.6.3/include/c++/cstdint:35:0,
                 from src\cmd_queue.h:17,
                 from src\cmd_queue.cpp:1:
e:\code\gcc\pcxmingw463\bin\../lib/gcc/i686-w64-mingw32/4.6.3/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

It means I need to set some extra compiler options.

But using

Code

#include "stdint.h"

works OK.

BTW:
Can you make the macro replacement on the GDB initial command?
I would like such:

Code

source $(TARGET_COMPILER_DIR)bin\my.gdb

instead of

Code

source E:\code\gcc\PCXMinGW463\bin\my.gdb

Thanks.

[oBFusCATed]

But using

Code

#include "stdint.h"

works OK.

Why would you use quotes instead of angled brackets? If it works with the brackets I could change it...

Can you make the macro replacement on the GDB initial command?

OK

[ollydbg]

But using

Code

#include "stdint.h"

works OK.

Why would you use quotes instead of angled brackets? If it works with the brackets I could change it...

Oh, this is a mistake. It should be

Code

#include <stdint.h>

Because its a system header. So, I changed it, and it works Ok.

Can you make the macro replacement on the GDB initial command?

OK

Thanks. I'm also hoping this gdb_mi plugin be put in the C::B trunk.

[ollydbg]

Thanks. I'm also hoping this gdb_mi plugin be put in the C::B trunk.

Ping!!!

BTW, I have see an issue that the debugee's output is mixed with gdb-mi's message in the console. Today, I see eran (author of Codelite have a solution), see:

http://sourceware.org/ml/gdb/2012-05/msg00063.html

Hope it will be fixed in the gdb_mi plugin too.

[oBFusCATed]

I don't understand...

[oBFusCATed]

Thanks. I'm also hoping this gdb_mi plugin be put in the C::B trunk.

Won't happen until it is usable...

[ollydbg]

I don't understand...

Under Windows, the message send from the debugee and the gdb_mi are in the same console input/output IO, which means the gdb_mi shared the same console with the debugee. This make parsing the messages from gdb_mi failure.
See:http://forums.codeblocks.org/index.php/topic,16230.msg109837.html#msg109837
This can be solved by eran's method.

[oBFusCATed]

Have you tried it?

[ollydbg]

Have you tried it?

I have tried today, but It looks like there is no new console shown if I use "-gdb-set new-console on".

I have another issue that the gdb-mi plugin does not response when I continually hit the "Next Line" command. (the running-cursor does not jump to the next line after some steps)

The log is below:

Code

[debug]ActionsMap::Run -> starting action: 02DDAE50 id: 20
[debug]RunAction::OnStart -> -exec-next
[debug]cmd==>200000000000-exec-next
[debug]output==>200000000000^running
[debug]output==>*running,thread-id="all"
[debug]unparsable_output==>(gdb)
[debug]RunAction success, the debugger is !stopped!
[debug]RunAction::Output - type: result
class: running
results:

[debug]Executor started
[debug]notification event recieved!
[debug]output==>*stopped,reason="end-stepping-range",frame={addr="0x0040176c",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="21"},thread-id="1",stopped-threads="all"
[debug]RunAction::destructor
[debug]unparsable_output==>(gdb)
[debug]notification event recieved!
[debug]Executor stopped
[debug]ActionsMap::Run -> starting action: 02D25460 id: 21
[debug]cmd==>210000000000-stack-info-frame
[debug]cmd==>210000000001-stack-list-frames 0 30
[debug]cmd==>210000000002-stack-list-arguments 1 0 30
[debug]ActionsMap::Run -> starting action: 0505E2E0 id: 22
[debug]cmd==>220000000000-thread-info
[debug]ActionsMap::Run -> starting action: 05C98BE0 id: 23
[debug]cmd==>230000000000-var-create - @ "s"
[debug]ActionsMap::Run -> starting action: 05C99DE0 id: 24
[debug]cmd==>240000000000-var-update 1 *
[debug]output==>210000000000^done,frame={level="0",addr="0x0040176c",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="21"}
[debug]unparsable_output==>(gdb)
[debug]output==>210000000001^done,stack=[frame={level="0",addr="0x0040176c",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="21"}]
[debug]unparsable_output==>(gdb)
[debug]output==>210000000002^done,stack-args=[frame={level="0",args=[]}]
[debug]unparsable_output==>(gdb)
[debug]output==>220000000000^done,threads=[{id="1",target-id="Thread 5516.0x1584",frame={level="0",addr="0x0040176c",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="21"},state="stopped"}],current-thread-id="1"
[debug]unparsable_output==>(gdb)
[debug]output==>230000000000^error,msg="-var-create: unable to create variable object"
[debug]unparsable_output==>(gdb)
[debug]output==>240000000000^done,changelist=[]
[debug]unparsable_output==>(gdb)
[debug]GenerateBacktrace::OnCommandOutput: tuple size 1 stack=[frame={level=0,addr=0x0040176c,func=main,file=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,fullname=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,line=21}]
[debug]GenerateBacktrace::OnCommandOutput arguments
[debug]WatchCreateAction::OnCommandOutput - processing command 230000000000
[debug]WatchCreateAction::OnCommandOutput - error in command: 230000000000
[debug]updating watches
[debug]WatchUpdateAction::Output - finishing at240000000000
[debug]updating watches
[debug]ActionsMap::Run -> starting action: 02DDADA0 id: 25
[debug]RunAction::OnStart -> -exec-next
[debug]cmd==>250000000000-exec-next
[debug]output==>250000000000^running
[debug]output==>*running,thread-id="all"
[debug]unparsable_output==>(gdb)
[debug]RunAction success, the debugger is !stopped!
[debug]RunAction::Output - type: result
class: running
results:

[debug]Executor started
[debug]notification event recieved!
[debug]output==>*stopped,reason="end-stepping-range",frame={addr="0x00401783",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="22"},thread-id="1",stopped-threads="all"
[debug]RunAction::destructor
[debug]unparsable_output==>(gdb)
[debug]notification event recieved!
[debug]Executor stopped
[debug]ActionsMap::Run -> starting action: 02D25460 id: 26
[debug]cmd==>260000000000-stack-info-frame
[debug]cmd==>260000000001-stack-list-frames 0 30
[debug]cmd==>260000000002-stack-list-arguments 1 0 30
[debug]ActionsMap::Run -> starting action: 0505E2E0 id: 27
[debug]cmd==>270000000000-thread-info
[debug]ActionsMap::Run -> starting action: 05C99DE0 id: 28
[debug]cmd==>280000000000-var-create - @ "s"
[debug]ActionsMap::Run -> starting action: 05C977E0 id: 29
[debug]cmd==>290000000000-var-update 1 *
[debug]output==>260000000000^done,frame={level="0",addr="0x00401783",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="22"}
[debug]unparsable_output==>(gdb)
[debug]output==>260000000001^done,stack=[frame={level="0",addr="0x00401783",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="22"}]
[debug]unparsable_output==>(gdb)
[debug]output==>260000000002^done,stack-args=[frame={level="0",args=[]}]
[debug]unparsable_output==>(gdb)
[debug]output==>270000000000^done,threads=[{id="1",target-id="Thread 5516.0x1584",frame={level="0",addr="0x00401783",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="22"},state="stopped"}],current-thread-id="1"
[debug]unparsable_output==>(gdb)
[debug]output==>280000000000^error,msg="-var-create: unable to create variable object"
[debug]unparsable_output==>(gdb)
[debug]output==>290000000000^done,changelist=[]
[debug]unparsable_output==>(gdb)
[debug]GenerateBacktrace::OnCommandOutput: tuple size 1 stack=[frame={level=0,addr=0x00401783,func=main,file=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,fullname=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,line=22}]
[debug]GenerateBacktrace::OnCommandOutput arguments
[debug]WatchCreateAction::OnCommandOutput - processing command 280000000000
[debug]WatchCreateAction::OnCommandOutput - error in command: 280000000000
[debug]updating watches
[debug]WatchUpdateAction::Output - finishing at290000000000
[debug]updating watches
[debug]ActionsMap::Run -> starting action: 02DDAE50 id: 30
[debug]RunAction::OnStart -> -exec-next
[debug]cmd==>300000000000-exec-next
[debug]output==>300000000000^running
[debug]output==>*running,thread-id="all"
[debug]unparsable_output==>(gdb)
[debug]output==>*stopped,reason="end-stepping-range",frame={addr="0x0040178f",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="23"},thread-id="1",stopped-threads="all"
[debug]unparsable_output==>(gdb)
[debug]RunAction success, the debugger is !stopped!
[debug]RunAction::Output - type: result
class: running
results:

[debug]Executor started
[debug]notification event recieved!
[debug]notification event recieved!
[debug]Executor stopped
[debug]RunAction::destructor
[debug]ActionsMap::Run -> starting action: 02D25460 id: 31
[debug]cmd==>310000000000-stack-info-frame
[debug]cmd==>310000000001-stack-list-frames 0 30
[debug]cmd==>310000000002-stack-list-arguments 1 0 30
[debug]ActionsMap::Run -> starting action: 0505E2E0 id: 32
[debug]cmd==>320000000000-thread-info
[debug]ActionsMap::Run -> starting action: 05C977E0 id: 33
[debug]cmd==>330000000000-var-create - @ "s"
[debug]ActionsMap::Run -> starting action: 05C98B60 id: 34
[debug]cmd==>340000000000-var-update 1 *
[debug]output==>310000000000^done,frame={level="0",addr="0x0040178f",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="23"}
[debug]unparsable_output==>(gdb)
[debug]output==>310000000001^done,stack=[frame={level="0",addr="0x0040178f",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="23"}]
[debug]unparsable_output==>(gdb)
[debug]output==>310000000002^done,stack-args=[frame={level="0",args=[]}]
[debug]unparsable_output==>(gdb)
[debug]output==>320000000000^done,threads=[{id="1",target-id="Thread 5516.0x1584",frame={level="0",addr="0x0040178f",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="23"},state="stopped"}],current-thread-id="1"
[debug]unparsable_output==>(gdb)
[debug]output==>330000000000^error,msg="-var-create: unable to create variable object"
[debug]unparsable_output==>(gdb)
[debug]output==>340000000000^done,changelist=[]
[debug]unparsable_output==>(gdb)
[debug]GenerateBacktrace::OnCommandOutput: tuple size 1 stack=[frame={level=0,addr=0x0040178f,func=main,file=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,fullname=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,line=23}]
[debug]GenerateBacktrace::OnCommandOutput arguments
[debug]WatchCreateAction::OnCommandOutput - processing command 330000000000
[debug]WatchCreateAction::OnCommandOutput - error in command: 330000000000
[debug]updating watches
[debug]WatchUpdateAction::Output - finishing at340000000000
[debug]updating watches
[debug]ActionsMap::Run -> starting action: 02DDAE50 id: 35
[debug]RunAction::OnStart -> -exec-next
[debug]cmd==>350000000000-exec-next
[debug]output==>350000000000^running
[debug]output==>*running,thread-id="all"
[debug]unparsable_output==>(gdb)
[debug]output==>*stopped,reason="end-stepping-range",frame={addr="0x004017c1",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="24"},thread-id="1",stopped-threads="all"
[debug]unparsable_output==>(gdb)
[debug]RunAction success, the debugger is !stopped!
[debug]RunAction::Output - type: result
class: running
results:

[debug]Executor started
[debug]notification event recieved!
[debug]notification event recieved!
[debug]Executor stopped
[debug]RunAction::destructor
[debug]ActionsMap::Run -> starting action: 02D25460 id: 36
[debug]cmd==>360000000000-stack-info-frame
[debug]cmd==>360000000001-stack-list-frames 0 30
[debug]cmd==>360000000002-stack-list-arguments 1 0 30
[debug]ActionsMap::Run -> starting action: 0505E2E0 id: 37
[debug]cmd==>370000000000-thread-info
[debug]ActionsMap::Run -> starting action: 05C98B60 id: 38
[debug]cmd==>380000000000-var-create - @ "s"
[debug]ActionsMap::Run -> starting action: 05C98A60 id: 39
[debug]cmd==>390000000000-var-update 1 *
[debug]output==>360000000000^done,frame={level="0",addr="0x004017c1",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="24"}
[debug]unparsable_output==>(gdb)
[debug]output==>360000000001^done,stack=[frame={level="0",addr="0x004017c1",func="main",file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="24"}]
[debug]unparsable_output==>(gdb)
[debug]output==>360000000002^done,stack-args=[frame={level="0",args=[]}]
[debug]unparsable_output==>(gdb)
[debug]output==>370000000000^done,threads=[{id="1",target-id="Thread 5516.0x1584",frame={level="0",addr="0x004017c1",func="main",args=[],file="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",fullname="E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp",line="24"},state="stopped"}],current-thread-id="1"
[debug]unparsable_output==>(gdb)
[debug]GenerateBacktrace::OnCommandOutput: tuple size 1 stack=[frame={level=0,addr=0x004017c1,func=main,file=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,fullname=E:\\code\\cb\\test_code\\gdbpython-demo\\main.cpp,line=24}]
[debug]GenerateBacktrace::OnCommandOutput arguments
[debug]output==>380000000000^error,msg="-var-create: unable to create variable object"
[debug]unparsable_output==>(gdb)
[debug]WatchCreateAction::OnCommandOutput - processing command 380000000000
[debug]WatchCreateAction::OnCommandOutput - error in command: 380000000000
[debug]updating watches

EDIT: It looks like this is the gdb issue, I can reproduce this in both CLI and MI mode. I'm currently testing a gdb 2012-06-13 build, now, I revert to gdb 2012-06-09 build, and there is not such hang. Sorry for the noise.

[ollydbg]

I see a lot of log message like:

Code

unparsable_output==>(gdb)

or

[debug]unparsable_output==>&"warning: (Internal error: pc 0x112 in read in psymtab, but not in symtab.)\n"
[debug]unparsable_output==>&"\n"

BTW: when using gdb-mi plugin, I see some messages were show in red color, does this by design?
See the image below:

[oBFusCATed]

Yes, this is by design.

[ollydbg]

Patch(git) to enable the macro replacement in gdb initial command

Code

81fe21e1490c3f85e023f310340c2b62e90a3fb2
 debbugger_gdbmi/src/config.cpp |   12 ++++++++----
 debbugger_gdbmi/src/config.h   |    2 +-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/debbugger_gdbmi/src/config.cpp b/debbugger_gdbmi/src/config.cpp
index 49eeaa8..cf060f8 100644
--- a/debbugger_gdbmi/src/config.cpp
+++ b/debbugger_gdbmi/src/config.cpp
@@ -118,12 +118,16 @@ wxString Configuration::GetDebuggerExecutable(bool expandMacros)
     return result;
 }
 
-wxArrayString Configuration::GetInitialCommands()
+wxArrayString Configuration::GetInitialCommands(bool expandMacros)
 {
     wxArrayString commands;
-    wxString const &init = m_config.Read(wxT("init_commands"), wxEmptyString);
-    if (!init.empty())
-        commands = GetArrayFromString(init, wxT('\n'));
+    wxString init = m_config.Read(wxT("init_commands"), wxEmptyString);
+    if (!init.empty())
+    {
+        if (expandMacros)
+            Manager::Get()->GetMacrosManager()->ReplaceEnvVars(init);
+        commands = GetArrayFromString(init, wxT('\n'));
+    }
     return commands;
 }
 
diff --git a/debbugger_gdbmi/src/config.h b/debbugger_gdbmi/src/config.h
index 861fadb..205dc89 100644
--- a/debbugger_gdbmi/src/config.h
+++ b/debbugger_gdbmi/src/config.h
@@ -59,7 +59,7 @@ public:
     virtual bool SaveChanges(wxPanel *panel);
 public:
     wxString GetDebuggerExecutable(bool expandMacros = true);
-    wxArrayString GetInitialCommands();
+    wxArrayString GetInitialCommands(bool expandMacros = true);
     wxString GetInitialCommandsString();
 
     enum Flags

Patch(git) to build fix on mingw port:

Code

 debbugger_gdbmi/src/cmd_queue.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debbugger_gdbmi/src/cmd_queue.h b/debbugger_gdbmi/src/cmd_queue.h
index 083fc6e..c15a800 100644
--- a/debbugger_gdbmi/src/cmd_queue.h
+++ b/debbugger_gdbmi/src/cmd_queue.h
@@ -12,7 +12,8 @@
 /*
 #include <wx/thread.h>
 class PipedProcess;
-*/
+*/
+#include <stdint.h>
 
 namespace dbg_mi
 {

[Pecan]

For my education, would someone tell me where m_executor is initialized in this constructor?

Code

// constructor
Debugger_GDB_MI::Debugger_GDB_MI() :
    cbDebuggerPlugin(wxT("GDB/MI"), wxT("gdbmi_debugger")),
    m_project(nullptr),
    m_execution_logger(this),
    m_command_stream_dialog(nullptr),
    m_console_pid(-1),
    m_pid_attached(0)
{
    // Make sure our resources are available.
    // In the generated boilerplate code we have no resources but when
    // we add some, it will be nice that this code is in place already ;)
    if(!Manager::LoadResource(_T("debugger_gdbmi.zip")))
    {
        NotifyMissingFile(_T("debugger_gdbmi.zip"));
    }

    m_executor.SetLogger(&m_execution_logger);
}

[oBFusCATed]

Default constructor?

[Pecan]

Default constructor?

It's your code bro. I'm really asking you.
Is it because namespace dbg_mi has to be initialized first?
Because class "GDBExecutor : public CommandExecutor" is a member of namespace dbg_mi?

[oBFusCATed]

Is it because namespace dbg_mi has to be initialized first?

What initialization?
C++ namespaces are used only for separating symbols and to prevent polluting the global namespace.
As far as I know there is no initialization.

And yes there is a default c-tor in the GDBExecutor, which is called implicitly by the c-tor of the plugin.

[Pecan]

Is it because namespace dbg_mi has to be initialized first?

What initialization?
C++ namespaces are used only for separating symbols and to prevent polluting the global namespace.
As far as I know there is no initialization.

And yes there is a default c-tor in the GDBExecutor, which is called implicitly by the c-tor of the plugin.

Of course, thanks. 

[ollydbg]

This is a detailed test on how the log message goes with gdb-mi.

Create a simple wxWidgets application, by default, it was a GUI application, so no console window will show when the app runs.
Put the code in the app's init stage

Code

wxLog::SetActiveTarget(new wxLogStderr());

Put the code in one event handler of the wxFrame:

Code

wxLogMessage(wxT("HI from wxLogMessage"));
wxPuts(wxT("HI from wxPuts"));

Here are the test and result:
Set the project as a "GUI" project, build, run app under Codeblocks
Case one:
Run: no console was created, no "HI" messages.
Case two:
Run under gdb-mi debugger plugin: no console was created, and the "HI from wxLogMessage" will shown in the gdb-mi console, the log looks like:

[debug]unparsable_output==>&"warning: 16:47:44: HI from wxLogMessage\r\n"
[debug]unparsable_output==>&"\n"

Set the project as a "console" project, build, run app under Codeblocks
Case three:
Run: console window was show, and both messages were shown in the console like below:

16:58:42: HI from wxLogMessage
HI from wxPuts

Case four:
Run under gdb-mi plugin: The same as Case three, besides that, the gdb-mi also receive the wxLogMessage like case Two.

Set the project as a "console" project, build, run app under Windows Shell gdb command line.
Case five:
Start the gdb like:

E:\code\cb\test_code\wxLogMessageVswxPuts\bin\Debug>gdb.exe --interpreter=mi wxLogMessageVswxPuts.exe

Then hit "r" command, there will be three message show in the gdb's console

17:05:10: HI from wxLogMessage
&"warning: 17:05:10: HI from wxLogMessage\r\n"
&"\n"
HI from wxPuts

Case six:
Start the gdb like:

E:\code\cb\test_code\wxLogMessageVswxPuts\bin\Debug>gdb.exe --interpreter=mi wxLogMessageVswxPuts.exe

Then enter "-gdb-set new-console on", then "r" command

The result is:

17:11:32: HI from wxLogMessage
HI from wxPuts

the above message will go to the new-console, and the gdb-mi console will still receive an ugly message:

&"warning: 17:11:32: HI from wxLogMessage\r\n"
&"\n

So, as a conclusion:
1, I prefer use wxPuts if I would like to debug under gdb-mi, otherwise, those "warnings" are annoying.
2, I use "-gdb-set new-console on", this is currently the only way to create a new console under gdb-mi.

[ollydbg]

OK, the issue(stated in the previous post) of wxLogMessage was solved.
To avoid the wxLogMessage pullets the GDB-MI logs, you should create

Code

wxLog::SetActiveTarget(new wxLogStderr(stdout));

Note, use "stdout", if you leave the parameter empty, it will be "stderr" by default, thus cause the GDB-MI report the annoying message.
See: wxLogStderr


Another patch to fix the build error: (as the compiler interface has changed in rev 8457: * compiler: Major refactor - remove the generator object from the compiler;)

Code

 debbugger_gdbmi/src/plugin.cpp | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/debbugger_gdbmi/src/plugin.cpp b/debbugger_gdbmi/src/plugin.cpp
index 4573f2a..1458070 100644
--- a/debbugger_gdbmi/src/plugin.cpp
+++ b/debbugger_gdbmi/src/plugin.cpp
@@ -9,6 +9,7 @@
 #include <cbdebugger_interfaces.h>
 #include <cbproject.h>
 #include <compilerfactory.h>
+#include <compilercommandgenerator.h>
 #include <configurationpanel.h>
 #include <configmanager.h>
 //#include <editbreakpointdlg.h>
@@ -17,6 +18,7 @@
 #include <pipedprocess.h>
 #include <projectmanager.h>
 
+
 #include "actions.h"
 #include "cmd_result_parser.h"
 #include "config.h"
@@ -53,7 +55,9 @@ wxString GetLibraryPath(const wxString &oldLibPath, Compiler *compiler, ProjectB
         wxString newLibPath;
         const wxString libPathSep = platform::windows ? _T(";") : _T(":");
         newLibPath << _T(".") << libPathSep;
-        newLibPath << GetStringFromArray(compiler->GetLinkerSearchDirs(target), libPathSep);
+        CompilerCommandGenerator *generator = compiler->GetCommandGenerator(target->GetParentProject());
+        newLibPath << GetStringFromArray(generator->GetLinkerSearchDirs(target), libPathSep);
+        delete generator;
         if (newLibPath.Mid(newLibPath.Length() - 1, 1) != libPathSep)
             newLibPath << libPathSep;
         newLibPath << oldLibPath;

 

[oBFusCATed]

Current state:
1. Many of the features are in state "not implemented", build and inspect the warnings to see them.
2. Watches handling is unstable, I've started to do a test case runner tool but I have not time.
    This is high priority and nothing will be done on the plugin until I have this tool.
3. I'm sure there are tons of bugs, because I'm not using it in production, because of 2

p.s. please edit your first post with the link to github, in case someone is interested in testing it.

[ollydbg]

Current state:
1. Many of the features are in state "not implemented", build and inspect the warnings to see them.
2. Watches handling is unstable, I've started to do a test case runner tool but I have not time.
    This is high priority and nothing will be done on the plugin until I have this tool.
3. I'm sure there are tons of bugs, because I'm not using it in production, because of 2

Oh, yes I see there are a log of

Code

#warning "not implemented"

in the source code those function should be done.

p.s. please edit your first post with the link to github, in case someone is interested in testing it.

Done.

[ollydbg]

This is the patch to fix building and running issue under MinGW

Code

 debbugger_gdbmi.cbp | 11 ++++++-----
 src/cmd_queue.h     | 22 ++++++++++++----------
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/debbugger_gdbmi.cbp b/debbugger_gdbmi.cbp
index 0514778..a37c1ac 100644
--- a/debbugger_gdbmi.cbp
+++ b/debbugger_gdbmi.cbp
@@ -35,8 +35,8 @@
 				<Option output="debugger_gdbmi" prefix_auto="0" extension_auto="1" />
 				<Option type="3" />
 				<Option compiler="gcc" />
-				<Option parameters='/ns /nd /na --multiple-instance /nc /d /p &quot;debug&quot;' />
-				<Option host_application="C:\dev\cb_dev\debugger1\src\devel\codeblocks.exe" />
+				<Option parameters="--debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose --profile=debug" />
+				<Option host_application="$(#cb_sdk)/devel/codeblocks.exe" />
 				<Option run_host_application_in_terminal="0" />
 				<Compiler>
 					<Add option="-Wall" />
@@ -47,15 +47,16 @@
 					<Add option="-DwxUSE_UNICODE" />
 					<Add option="-DBUILDING_PLUGIN" />
 					<Add directory="$(#WX.include)" />
-					<Add directory="$(#wx)\contrib\include" />
-					<Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)" />
+					<Add directory="$(#wx)/contrib/include" />
+					<Add directory="$(#WX.lib)/gcc_dll$(WX_CFG)/msw$(WX_SUFFIX)" />
 				</Compiler>
 				<Linker>
 					<Add option="-Wl,--enable-auto-image-base" />
 					<Add option="-Wl,--add-stdcall-alias" />
 					<Add option="-Wl,--enable-auto-import" />
 					<Add library="wxmsw28U" />
-					<Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)" />
+					<Add directory="$(#WX.lib)/gcc_dll$(WX_CFG)" />
+					<Add directory="$(#cb_sdk)/devel" />
 				</Linker>
 				<ExtraCommands>
 					<Add after="pack.bat $(#cb_sdk)" />
diff --git a/src/cmd_queue.h b/src/cmd_queue.h
index 083fc6e..8579069 100644
--- a/src/cmd_queue.h
+++ b/src/cmd_queue.h
@@ -14,6 +14,8 @@
 class PipedProcess;
 */
 
+#include <stdint.h> //int32_t under MinGW
+
 namespace dbg_mi
 {
 
@@ -289,19 +291,19 @@ public:
 
         wxString line;
         Type type;
-    };
-
-    struct Log
-    {
-        enum Type
-        {
-            Normal = 0,
-            Error
-        };
+    };
+
+    struct Log
+    {
+        enum Type
+        {
+            Normal = 0,
+            Error
+        };
     };
 public:
     virtual ~Logger() {}
-
+
     virtual void Log(wxString const &line, Log::Type type = Log::Normal) = 0;
     virtual void Debug(wxString const &line, Line::Type type = Line::Debug) = 0;
     virtual Line const* GetDebugLine(int index) const = 0;

BTW: there are a lot of CRLF and LF eol mixing in the git source code.

[ollydbg]

@obf: what about the patch in my previous post?

Another question:

Code

    virtual void OnCommandOutput(CommandID const &/*id*/, ResultParser const &result)
    {
        if(result.GetResultClass() == ResultParser::ClassRunning)
        {
            m_logger.Debug(wxT("RunAction success, the debugger is !stopped!"));
            m_logger.Debug(wxT("RunAction::Output - ") + result.MakeDebugString());
            m_notification(false);
        }
        Finish();
    }

"the debugger is !stopped!" means "the debugger is not stopped!" right?

Another build issue fix is that you should add a virtual function like:

Code

virtual void UpdateWatch(cb::shared_ptr<cbWatch> watch);

...

void Debugger_GDB_MI::UpdateWatch(cb::shared_ptr<cbWatch> watch)
{

}

I have some issue about creating the patch, because there are some LF and CRLF in plugin.cpp.

[oBFusCATed]

@obf: what about the patch in my previous post?

The plugin is in on-hold mode at the moment.
I have no intention to do any work on the plugin, until I have a proper test-suite-system for it.
I want to have some safety net, so I know that old features still work when I do changes.

If you like you can fork the repo, but don't expect to see your changes integrated in the plugin any soon.

Sorry but I can't spend any time on the plugin, because there more important things on the ToDo.

[ollydbg]

Put some record here.
I just see there are many messages like:

Code

[debug]unparsable_output==>(gdb)

When using the GDB/MI plugin, I just look at the GDB document, and I see that a full output contains this "(gdb)" token as the last token, see:GDB/MI Output Syntax - Debugging with GDB

output ==>
    ( out-of-band-record )* [ result-record ] "(gdb)" nl

So, this should be fixed in the future(since you are quite busy right now,  )

[yvesdm3000]

Has this GDB/MI project come to a halt ?

Yves

[oBFusCATed]

Sort of. I plan to restart it soon.

[yvesdm3000]

Biggest issue is that with an array of classes that contain a lot of other nested classes, stepping is no joy with the current implementation. Don't get me wrong, printing the object in gdb also takes minutes on this machine:

...
processor   : 23
vendor_id   : GenuineIntel
cpu family   : 6
model      : 63
model name   : Intel(R) Xeon(R) CPU E5-2643 v3 @ 3.40GHz

For now I disable the watches.

Yves

[oBFusCATed]

I know. The gdb/mi version should be faster, because it has less traffic and it is also sort of async. But until the find the time to work on it the state will be unchanged.