jasonmolenda wrote: Yeah, the problem with our current algorithm is that you lose the actual stop reason, and sometimes that's important. For instance, if you have a store instruction that modifies a watchpointed memory, and you have a user breakpoint on the next instruction, on AArch64, the store triggers the watchpoint. lldb reads the old value, instruction steps, reads the new value and then tells the user. But now it's sitting on a breakpoint site so that overwrites the watchpoint stop reason and we never tell the user about that - we tell it we've hit the breakpoint. gdb behaves the same way.
The user-visible down side to this new approach was seen with Dexter debuginfo engine, where it sets a breakpoint on every source line in a program, and then does step-in across the source lines. In this case, the step-in executes to the first instruction of the next source line (where there is a breakpoint). So we have a "step-in completed" stop reason. Then Dexter step-in's again, and now it executes the breakpoint instruction and stops, without having advanced the pc, with a "breakpoint hit" stop reason. *then* doing a step-in will advance to the next source line. Users will surely experience this (with only one breakpoint in code they're stepping over), and I'm sure they will scratch their heads about why they needed to Step twice to get past a breakpoint (if they notice at all), but that's the only bad fallout from this change to the algorithm. https://github.com/llvm/llvm-project/pull/108504 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
