Debugger plugin: GDB MI interface features and issues

[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 Select Expand

wxLog::SetActiveTarget(new wxLogStderr());
Put the code in one event handler of the wxFrame:

Code Select Expand

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 Select Expand

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 Select Expand


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 Select Expand

#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 Select Expand


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 Select Expand


    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 Select Expand


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 Select Expand


[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