[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