Author Topic: GDB with MI interface  (Read 8336 times)

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3352
GDB with MI interface
« on: July 31, 2017, 01:24:31 pm »
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....

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: GDB with MI interface
« Reply #1 on: July 31, 2017, 08:11:50 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3352
Re: GDB with MI interface
« Reply #2 on: July 31, 2017, 10:12:29 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: GDB with MI interface
« Reply #3 on: August 01, 2017, 12:58:01 am »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]