Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: Pecan on April 27, 2026, 09:49:45 pm

Title: Debugger_gdbmi plugin
Post by: Pecan on April 27, 2026, 09:49:45 pm
Installation Guide: Debugger GDB/MI Plugin
A CodeBlocks plugin using the machine interface of the GDB debugger.

Source is available at github Source (https://github.com/pecanh/debugger_gdbmi)
Preparation


.cbp files included:

Installation

Configuration

     After installation, restart CodeBlocks and go to Settings->Debugger->GDB/MI default

Usage
    Go to MainMenu->Debug->Active Debuggers and select GDB/MI default.

Report issues in the Help or Plugins Development forum thread with your Build log and OS.
Title: Re: Debugger_gdbmi plugin
Post by: killerbot on April 28, 2026, 08:03:27 am
wouldn't we add it to our normal source tree, as a contrib plug-in ?
Title: Re: Debugger_gdbmi plugin
Post by: Pecan on April 28, 2026, 05:06:31 pm
Quote from: killerbot on April 28, 2026, 08:03:27 am
wouldn't we add it to our normal source tree, as a contrib plug-in ?

Yes, but I'm trying to determine if there is any interest in it.
I've found that adding a plugin to the contribs and especially updating autoMake is very painful and error prone.
I'd rather avoid the pain if there's no interest.
Title: Re: Debugger_gdbmi plugin
Post by: MaxGaspa on April 28, 2026, 11:25:17 pm
Quote from: Pecan on April 28, 2026, 05:06:31 pm
Yes, but I'm trying to determine if there is any interest in it.

As far as I'm concerned I'm very interested to try a modern GDB/MI instead of using the old annotation mechanism. CB seems to be the last IDE still using the annotation mechanism. CLion, CodeLite. KDevelop, Eclipse, QTcreator...are all using GDB/MI.
Title: Re: Debugger_gdbmi plugin
Post by: SharkCZ on April 29, 2026, 11:58:01 am
I like that, thanks for your efforts in this area.
Title: Re: Debugger_gdbmi plugin
Post by: ollydbg on May 03, 2026, 05:09:52 pm
Code
[debug]ActionsMap::Run -> starting action: 0000000011aa5f50 id: 21
[debug]cmd==>210000000000-var-update 1 *
[debug]output==>210000000000^done,changelist=[{name="var5",value="std::vector of length 5, capacity 5",in_scope="true",type_changed="false",new_num_children="5",displayhint="array",dynamic="1",has_more="0"}]
[debug]cmd==>210000000001-var-list-children 2 "var5"
[debug]unparsable_output==>(gdb)
[debug]output==>210000000001^done,numchild="5",displayhint="array",children=[child={name="var5.[0]",exp="[0]",numchild="0",value="1",type="int"},child={name="var5.[1]",exp="[1]",numchild="0",value="2",type="int"},child={name="var5.[2]",exp="[2]",numchild="0",value="3",type="int"},child={name="var5.[3]",exp="[3]",numchild="0",value="4",type="int"},child={name="var5.[4]",exp="[4]",numchild="0",value="5",type="int"}],has_more="0"
[debug]unparsable_output==>(gdb)


question:

Is the "unparsable_output" correct? See the above log.
Title: Re: Debugger_gdbmi plugin
Post by: Pecan on May 03, 2026, 06:57:38 pm
Quote from: ollydbg on May 03, 2026, 05:09:52 pm
Code
[debug]ActionsMap::Run -> starting action: 0000000011aa5f50 id: 21
[debug]cmd==>210000000000-var-update 1 *
[debug]output==>210000000000^done,changelist=[{name="var5",value="std::vector of length 5, capacity 5",in_scope="true",type_changed="false",new_num_children="5",displayhint="array",dynamic="1",has_more="0"}]
[debug]cmd==>210000000001-var-list-children 2 "var5"
[debug]unparsable_output==>(gdb)
[debug]output==>210000000001^done,numchild="5",displayhint="array",children=[child={name="var5.[0]",exp="[0]",numchild="0",value="1",type="int"},child={name="var5.[1]",exp="[1]",numchild="0",value="2",type="int"},child={name="var5.[2]",exp="[2]",numchild="0",value="3",type="int"},child={name="var5.[3]",exp="[3]",numchild="0",value="4",type="int"},child={name="var5.[4]",exp="[4]",numchild="0",value="5",type="int"}],has_more="0"
[debug]unparsable_output==>(gdb)


question:

Is the "unparsable_output" correct? See the above log.

Yes. It's ok. It's left over from code inherited from the original CodeBlocks debugger plugin.
I seem to remember that I tried to eliminate it, but removing it just caused a whole bunch of problems.

The original debugger code set that line as the prompt to be sent back from from gdb.
On some commands to gdb, there is original plugin code that waits for multiple responses to be returned to CodeBlocks; debugger plugin goes idle before sending any more commands. The idle condition is keyed to that prompt to indicate the end of any more responses and clears the idle condition.

Since the original debugger code and prompt mechanism worked with debugger_gdbmi (and caused problems without it), I got lazy and just left it for now.

I'll put this in the "revisit latter" ToDo queue. I'd also like to eliminate it if I can.

Title: Re: Debugger_gdbmi plugin
Post by: gd_on on May 04, 2026, 08:04:30 pm
A few remarks on debugger_gdmi plugin.
I have created a debugger_gdmi folder Inside plugins\contrib and put inside a copy of your git repos.
I have added 3 lines in my CodeBlocks_Windows.workspace as it is for all other plugins.
Code
	<Project filename="plugins/contrib/debugger_gdmi/debugger_gdbmi_Windows.cbp">
		<Depends filename="CodeBlocks_Windows.cbp" />
	</Project>
Building C::B as usual, produces as previously my C::B version, but containing this time debugger_gdmi.zip and debugger_gdmi.dll at the correct place.

My first debug tries did not work as expected.
I find in your distribution a gdbinit file. It contains a path to print.py, but it does not match a path on my system. I tried to replace this path by the one I have (for example C:\wxWidgets-3.3.2\misc\gdb), but it does not seem to change something. Is this gdbinit file useful ?

Finally, I made it work by avoiding space and/or accentuated characters within the path to my executable. The standard debugger.dll (which uses the same gdb.exe) seems to be more tolerant with that.

Other points to notice :
- with standard debugger, when I open the watches window, all my local variables are displayed. With gdbmi, I have to add one by one an explicit Watch to my local variables. I can then follow the content of my variables step by step when executing.
- at the end of my program, if I try to restart it, while the watches window is still opened, I see my variables, but their content is not updated: 2 solutions here, open new watches on the same variables and I see that only the new ones are updated, or simply rename them but without really changing the name (just clic on return at the end of the variable name).

Last question : can we have both plugins (standard and gdmi) activated ? Or is it better to have only one activated (as for codecompletion and clangd_client) ?
Title: Re: Debugger_gdbmi plugin
Post by: ollydbg on May 05, 2026, 02:33:08 am
Quote from: gd_on on May 04, 2026, 08:04:30 pm
Last question : can we have both plugins (standard and gdmi) activated ? Or is it better to have only one activated (as for codecompletion and clangd_client) ?

Yes, you can have both of the 2 debugger plugins enabled. There is a menu item: Debug->Active debuggers->You can select one.


Quote
- with standard debugger, when I open the watches window, all my local variables are displayed. With gdbmi, I have to add one by one an explicit Watch to my local variables. I can then follow the content of my variables step by step when executing.
In the standard debugger plugin, this is the option: "Watch local variables". In the gdbmi plugin, I also see this option is ON, but I see the same issue here, which means local variables were not listed in the watches panel.

Title: Re: Debugger_gdbmi plugin
Post by: Pecan on May 05, 2026, 06:38:14 pm
@ gd_on and ollydbg

acknowledge; watches problems put on top of the ToDo list.

also, I'll remove the gdbinit file from the github repo. It should not be there.

debugger_gdbmi tries to create the file dynamically if it finds gdbinit missing and it can find a valid wxWidgets installation folder which contains print.py.
If it finds gdbini already created, it leave it as is, assuming that the user created it themselves.

ollydbg's description of activated multiple debuggers is correct.