GDB with MI interface

[BlueHazzard]

i tested today the gdb/mi plugin from https://github.com/obfuscated/cb_gdbmi
it is amazing how fast and reliable it works... Big watch structures are fetched and parsed insanely fast (on linux the old plugin works fine, but on windows it is really slow)

Is there any todo list i can look into? I would like to help to bring this forward....

[oBFusCATed]

There is one todo list item that blocks development - a way to regression test the plugin.
If there is no such system implemented the plugin will run in circles (I've already suffered it) - you fix one issue and another one pops up, you fix it and the first issue reappears. Not fun or stable way to develop something.
The worst thing is that I'm not sure how to do it.

But I know that I want it to be:
1. easy to run tests
2. reliable
3. easy to make add tests.

I think it is fine if the gdb command runner is separated from the plugin, so it is not required to start a full codeblocks instance to test the runner. But I think I want to issue commands to a live gdb and not a mocked version.

[BlueHazzard]

You are talking about, for example testing breakpoints:

1) Start test of breakpoint
2) test environment calls gdb with a test application as target
3) test environment  runs  "gdb command runner", connects to gdb and sets a breakpoint
4) test environment  runs the debugger via "gdb command runner"
5) target runs into breakpoint gdb halts and returns to "gdb command runner"
6) test environment checks the output of "gdb command runner"

So you need a test environment that support the gdb calls (this can probably integrated in the "gdb command runner" program?) . You need a (or multiple) target application that trigger different gdb events (various signals, exceptions, has multiple variables ecc.). I don't think there will be a "easy" way to add tests...
I can see that you have implemented some tests. Are you not satisfied with them?

[oBFusCATed]

You are talking about, for example testing breakpoints:

Yes, but for watches. Breakpoints are easy to get right. Watches aren't.

I can see that you have implemented some tests. Are you not satisfied with them?

No, I'm not. They are only scratching the surface. And don't handle watches... And the real output of different gdb versions.