Skip to content

Added conditional breakpoints #96

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

TamaMcGlinn
Copy link

Added support for conditional breakpoints for gdb. To test this; I used the following fizzbuzz in C++:

#include<iostream>
using std::cout;
using std::endl;

void print_fizzbuzz(int n) {
  const bool mod5 = n % 5 == 0;
  const bool mod3 = n % 3 == 0;
  if (mod3 && mod5) {
    cout << "FizzBuzz" << endl;
  } else if (mod3) {
    cout << "Fizz" << endl;
  } else if (mod5) {
    cout << "Buzz" << endl;
  } else {
    cout << n << endl;
  }
}

void fizzbuzz() {
  for (int i = 1; i <= 100; ++i) {
    print_fizzbuzz(i);
  }
}

int main() {
  fizzbuzz();
  return 0;
}

Using this branch, I can add a breakpoint for instance on line 6 with <vebugger-leader>k and then type in if n == 5. Everything I tested works:

  • Setting the breakpoint before or after the debugger has started
  • Toggling the breakpoint with or without a condition works; when removing, the condition passed in is ignored. The highlight correctly updates when you add conditional breakpoints, although you can't see the difference between a conditional breakpoint and a regular one.
  • Toggling normal breakpoints still works, because the empty string is passed as the condition, which will just add a space at the end of the command passed to the debugger, which it ignores.

Note: I have not yet tested other debuggers than gdb. Presumably we should add it for others that support it as well.

Adding support for #95 was easier than I thought!

@TamaMcGlinn
Copy link
Author

I should note that it is easy to mistakenly add a condition such as 'n == 5' instead, which will never be true. I'm not sure why gdb requires the if, and maybe it should be hidden inside vebugger, actually. That would mean we need to test if there is a non-empty condition, and only add 'if '.l:breakpoint.condition if the string is non-empty.

@TamaMcGlinn
Copy link
Author

Although it would still be better to show the condition of a conditional breakpoint as soon as you put the cursor over it, I just realised an easy way to show the condition is to edit it again using <vebugger-leader>k - if we can pre-populate the input window with the current condition, then you can just view it without editing and close it again, effectively recreating the same conditional breakpoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant