[all-commits] [llvm/llvm-project] 93e45a: [Dexter] Adapt to upcoming lldb stepping behavior ...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 93e45a69dde16e6a3ac0ddbcc596ac3843d59c43
      https://github.com/llvm/llvm-project/commit/93e45a69dde16e6a3ac0ddbcc596ac3843d59c43
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2024-09-11 (Wed, 11 Sep 2024)

  Changed paths:
    M cross-project-tests/debuginfo-tests/dexter/dex/debugger/lldb/LLDB.py

  Log Message:
  -----------
  [Dexter] Adapt to upcoming lldb stepping behavior (#108127)

lldb will change how it reports stop reasons around breakpoints in the
near future. I landed an earlier version of this change and noticed
debuginfo test failures on the CI bots due to the changes. I'm
addressing the issues found by CI at
https://github.com/llvm/llvm-project/pull/105594 and will re-land once
I've done all of them.

Currently, when lldb stops at a breakpoint instruction -- but has not
yet executed the instruction -- it will overwrite the thread's Stop
Reason with "breakpoint-hit". This caused bugs when the original stop
reason was important to the user - for instance, a watchpoint on an
AArch64 system where we have to instruction-step past the watchpoint to
find the new value. Normally we would instruction step, fetch the new
value, then report the user that a watchpoint has been hit with the old
and new values. But if the instruction after this access is a breakpoint
site, we overwrite the "watchpoint hit" stop reason (and related
actions) with "breakpoint hit".

dexter sets breakpoints on all source lines, then steps line-to-line,
hitting the breakpoints. But with this new behavior, we see two steps
per source line: The first step gets us to the start of the next line,
with a "step completed" stop reason. Then we step again and we execute
the breakpoint instruction, stop with the pc the same, and report
"breakpoint hit". Now we can step a second time and move past the
breakpoint.

I've changed the `step` method in LLDB.py to check if we step to a
breakpoint site but have a "step completed" stop reason -- in which case
we have this new breakpoint behavior, and we need to step a second time
to actually hit the breakpoint like the debuginfo tests expect.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications