Breakpoint support on Linux #108
Conversation
This test should be hardened by creating helpers that allow getting the list of instructions from Capstone, starting at a given address
I was referring to the situation where you hit a breakpoint and then when continuing the first instruction causes a fault. You need to make sure that you don't immediately set the breakpoint again such that continuing would run the instruction again instead of hitting the breakpoint, but you must also ensure that when the instruction does succeed this time the breakpoint is set again. |
|
This hit the spurious #116. The good news is that all other tests pass! |
There was a problem hiding this comment.
Great work @Arthamys, thank you!
I've added a couple of general comments about future work, and there is a couple of minor typos.
Would you prefer to address them in this PR, or raise a separate one?
| self.breakpoints.borrow_mut().insert(addr, bp.clone()); | ||
| bp | ||
| } | ||
| // If there is already a breakpoint set, we give back the existing one |
There was a problem hiding this comment.
In this case, we might need to support multiple breakpoints set in one place. For example, for breakpoints with different conditions (watching variables), and for the case of 'internal' breakpoints (i.e. the ones set by the debugger itself). I believe that's a separate issue, though, and should be tackled with a separate PR.
There was a problem hiding this comment.
Watching variables could be handled by a wrapper around LinuxTarget. The code should be relatively platform independent. Setting multiple breakpoints could also be handled by such wrapper.
There was a problem hiding this comment.
Having more involved types of breakpoints is of course something that we should tackle, but as you suggested, it should probably be part of another PR once we have breakpoints support on another platform than Linux.
|
Thanks a lot! Do you want to make a follow up to remove the patch breakpoint function hack from the repl and tests? |
|
Yes, I'll get on that tomorrow! |
Here is a first version that supports setting and removing breakpoints, as well as a single_step function.
I wanted to get your feedback on the interface, as well as some inputs on the edge cases that should be handled.
Bjorn mentioned in #55 that code should handle "faulting instructions at the place of the breakpoint" but I don't know what should be the particular reaction we should have in this situation. Should we not allow settings the breakopint?