I have tried OBF's new debugger plugin which use GDB-MI interface.
GIT source address
https://github.com/obfuscated/cb_gdbmi
EDIT 2013-05-09 : the current status of this plugin is Here (http://forums.next.codeblocks.org/index.php/topic,16230.msg122400.html#msg122400)
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)
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!!!
Quote from: ollydbg on April 21, 2012, 05:24:26 AM
So, I add such code snippet:(in src\cmd_queue.h)
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?)
Quote from: MortenMacFly on April 21, 2012, 06:02:11 AM
Quote from: ollydbg on April 21, 2012, 05:24:26 AM
So, I add such code snippet:(in src\cmd_queue.h)
typedef int int32_t;
typedef long int int64_t;
You should better include <cstdint> (stdint.h).
OK, I will try it, thanks.
Quote
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.
@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?
Quote from: oBFusCATed on April 21, 2012, 08:10:23 AM
@admins: Can you move the topic in the plugins section?
Done !
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.
Quote from: oBFusCATed on April 21, 2012, 08:10:23 AM
@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...).
Quote from: ollydbg on April 21, 2012, 05:24:26 AM
I have tried OBF's new debugger plugin which use GDB-MI interface.
SVN address
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?
Quote from: ollydbg on April 21, 2012, 11:41:34 AM
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.
Quote from: Pecan on April 21, 2012, 01:33:10 PM
Quote from: ollydbg on April 21, 2012, 05:24:26 AM
I have tried OBF's new debugger plugin which use GDB-MI interface.
SVN address
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. :)
QuoteHave 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)
Quote
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.next.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 (http://forums.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) 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. :)
Quote from: oBFusCATed on April 21, 2012, 01:55:56 PM
Quote from: ollydbg on April 21, 2012, 11:41:34 AM
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!
Quote from: oBFusCATed on April 21, 2012, 01:55:56 PM
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.
Quote from: ollydbg on April 21, 2012, 02:19:58 PM
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?
Quote from: Pecan on April 22, 2012, 03:24:57 PM
Quote from: ollydbg on April 21, 2012, 02:19:58 PM
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:
...
[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"
...
Quote from: ollydbg on April 23, 2012, 01:49:27 AM
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:
--- 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
Quote from: ollydbg on April 23, 2012, 01:49:27 AM
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?
Quote from: ollydbg
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?
4G, but I don't think that's the crash reason. gdb takes 180M.
Ollydbg: I've committed your patch, thank you.
Quote from: MortenMacFly on April 21, 2012, 06:02:11 AM
Quote from: ollydbg on April 21, 2012, 05:24:26 AM
So, I add such code snippet:(in src\cmd_queue.h)
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:
#include <cstdint>
I will have a build error
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
#include "stdint.h" works OK.
BTW:
Can you make the macro replacement on the GDB initial command?
I would like such:
source $(TARGET_COMPILER_DIR)bin\my.gdb
instead of
source E:\code\gcc\PCXMinGW463\bin\my.gdb
Thanks.
Quote from: ollydbg on April 27, 2012, 03:27:46 AM
But using
#include "stdint.h" works OK.
Why would you use quotes instead of angled brackets? If it works with the brackets I could change it...
Quote from: ollydbg on April 27, 2012, 03:27:46 AM
Can you make the macro replacement on the GDB initial command?
OK
Quote from: oBFusCATed on April 27, 2012, 08:16:13 AM
Quote from: ollydbg on April 27, 2012, 03:27:46 AM
But using
#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
#include <stdint.h>
Because its a system header. So, I changed it, and it works Ok.
Quote
Quote from: ollydbg on April 27, 2012, 03:27:46 AM
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. :)
Quote from: ollydbg on April 27, 2012, 09:39:01 AM
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.
I don't understand...
Quote from: ollydbg on April 27, 2012, 09:39:01 AM
Thanks. I'm also hoping this gdb_mi plugin be put in the C::B trunk. :)
Won't happen until it is usable...
Quote from: oBFusCATed on May 15, 2012, 10:03:43 AM
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.next.codeblocks.org/index.php/topic,16230.msg109837.html#msg109837
This can be solved by eran's method.
Have you tried it?
Quote from: oBFusCATed on May 15, 2012, 10:38:14 AM
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:
[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
I see a lot of log message like:
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:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-06-13112130.png)
Yes, this is by design.
Patch(git) to enable the macro replacement in gdb initial command
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:
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
{
For my education, would someone tell me where m_executor is initialized in this constructor?
// 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);
}
Default constructor?
Quote from: oBFusCATed on June 27, 2012, 11:39:04 PM
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?
Quote from: Pecan on June 27, 2012, 11:49:35 PM
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.
Quote from: oBFusCATed on June 27, 2012, 11:59:21 PM
Quote from: Pecan on June 27, 2012, 11:49:35 PM
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. :-[
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
wxLog::SetActiveTarget(new wxLogStderr());Put the code in one event handler of the wxFrame:
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 CodeblocksCase 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:
Quote
[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 CodeblocksCase three:Run: console window was show, and both messages were shown in the console like below:
Quote16: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:
QuoteE:\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
Quote17:05:10: HI from wxLogMessage
&"warning: 17:05:10: HI from wxLogMessage\r\n"
&"\n"
HI from wxPuts
Case six:Start the gdb like:
QuoteE:\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:
Quote17: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:
Quote&"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.
OK, the issue(stated in the previous post) of wxLogMessage was solved.
To avoid the wxLogMessage pullets the GDB-MI logs, you should create
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 (http://docs.wxwidgets.org/2.8/wx_wxlogstderr.html#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;)
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;
:)
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.
Quote from: oBFusCATed on May 09, 2013, 08:10:07 AM
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
#warning "not implemented"in the source code those function should be done.
Quote
p.s. please edit your first post with the link to github, in case someone is interested in testing it.
Done.
This is the patch to fix building and running issue under MinGW
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 "debug"' />
- <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.
@obf: what about the patch in my previous post?
Another question:
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:
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. :(
Quote from: ollydbg on October 25, 2013, 05:58:35 PM
@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. :(
Put some record here.
I just see there are many messages like:
[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 (https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax)
Quote
output ==>
( out-of-band-record )* [ result-record ] "(gdb)" nl
So, this should be fixed in the future(since you are quite busy right now, :) )
Has this GDB/MI project come to a halt ?
Yves
Sort of. I plan to restart it soon.
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
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.