Added Conditional Breakpoint Support

[3rdit]

PR Overview

This PR adds conditional breakpoint support to the debugger, allowing a user to specify expressions that must evaluate to true for the breakpoint to actually trigger. This is implemented at the debugger core level (not adapter level), so it works the same across all adapters.

As discussed with @xusheng6:

The conditions for breakpoints are written using the expression parser (i.e. $rax == 0) making it the exact same for each debugger. The API now has:

• C++: SetBreakpointCondition(), GetBreakpointCondition() on DebuggerController
• Python: set_breakpoint_condition(), get_breakpoint_condition()

For example:

controller->SetBreakpointCondition(address, "$rax == 0");
std::string cond = controller->GetBreakpointCondition(address);

controller.set_breakpoint_condition(addr, "$rbx > 100")
cond = controller.get_breakpoint_condition(addr)

In the breakpoint widget, there's a new "Condition" column that can be set by right-clicking and pressing "Edit Condition...", this works in the widget and disassembly view.

The condition is also persistent across sessions (saved to the binary view metadata).

Upcoming Changes

• Condition validation on the input dialog; the idea being to stop users from entering invalid expressions (this is tricky to add due to the way the expression parser works, not going to do this)
• Possibility of adding hit counts, e.g., break after N hits
• It makes sense to have some sort of unit testing for this. I reviewed the unit testing and noticed how breakpoints get tested in debugger_test.py, it would be trivial to add a quick unit test for conditions.
• Adding callbacks for conditional breakpoints being hit (Support callback when a breakpoint is hit #422). That may be out of scope for this PR albeit and @xusheng6 will need to advise.

This PR will close #93 and maybe close #422 (if the feature above is approved to be added in this PR).

[xusheng6]

Hi @3rdit I will review this ASAP and let you know what I think

For context, I am working on a different PR that adds hardware breakpoint #53. And in light of the hardware breakpoint, I plan to make another large refactor on the breakpoint handling, e.g., the added breakpoints will be referred to by their index, not their address, etc.

This would mean some non-trivial merge conflict in the future. However, I hope to minimize the frictions for you as you are doing these all for free. I will most likely review and merge your PR first, and brace for the merge conflicts on my branch. Hopefully that will be manageable

[xusheng6]

I am not a big fan of m_conditions here. I know you are copying the m_enabledState pattern, but that is really just a quick and dirty way to add "enable/disable" breakpoint into the product without a full refactor (a refactor on the breakpoint is already planned, but we wanted to slip that feature into the debugger before the refactor lands).

Ideally we would want something like this

  struct Breakpoint {
      ModuleNameAndOffset address;
      bool enabled = true;
      std::string condition;
  };

which is apparently better in terms of how to keep things more organized. I will make a decision on whether or not to integrate the refactor with this PR

[3rdit]

I like this idea. I've followed your code patterns to keep it all consistent.

I've refactored the three separate variables into a BreakpointEntry struct (named to avoid a conflict with the enum) stored in a single vector. FindBreakpoint will now return an iterator directly to avoid redundant lookups when modifying or erasing entries. This reduces complexity in the lookups/logic and should make your planned refactor easier to do.

See: 9eb418b and b322922

[xusheng6]

@3rdit I have a look at the code today and it looks good to me in general. I also did functionality tests and it works like a charm. I will see how the unit test goes

Most likely I will take over this PR and make some changes to it, and then merge it. I will keep you posted. Thanks again for the contribution!