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?