[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)
Jason Molenda via lldb-commits
lldb-commits at lists.llvm.org
Fri Jul 19 19:05:54 PDT 2024
jasonmolenda wrote:
I've reverted this change until I can debug the failures found on the CI bots.
Two debuginfo dexter tests failed, likely because the way stepping and breakpoints works is now different. If you're sitting at a BreakpointSite which has not yet executed, previously lldb would overwrite the stop reason with "breakpoint hit" even though it had not been hit. Now, you'll have your actual stop reason -- and when you resume, you'll hit the breakpoint and stop again. If you 'continue', it stops again. If you 'next/step', it stops again and your next/step is still on the thread plan stack, so if you 'continue', you're going to first do the next/step that was on the thread stack, and then you can do your other command.
I've spent a lot of time thinking about any other approach to this, and they all have bad outcomes that we don't want to add.
In short, I expect the debuginfo tests are continuing from a breakpoint and not expecting the breakpoint to be hit.
The ubuntu-arm bot failed TestConsecutiveBreakpoints.py and TestConsecutiveBreakpoints.py, but it seems like the only failure text was like "process exited -9" or something. I may need to re-land the patch with a lot more logging enabled on these two, to narrow down what this bot is seeing. I let it run an extra cycle and it failed in the same spot again, so it wasn't a oneoff error.
https://github.com/llvm/llvm-project/pull/96260
More information about the lldb-commits
mailing list