[all-commits] [llvm/llvm-project] 213c59: [lldb] Add pc check for thread-step-by-bp algorith...

[Jason Molenda via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 213c59ddd2a702ddd3d849cea250440b1ed718e0
      https://github.com/llvm/llvm-project/commit/213c59ddd2a702ddd3d849cea250440b1ed718e0
  Author: Jason Molenda <jmolenda at apple.com>
  Date:   2024-09-13 (Fri, 13 Sep 2024)

  Changed paths:
    M lldb/source/Plugins/Process/FreeBSD/NativeProcessFreeBSD.cpp
    M lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

  Log Message:
  -----------
  [lldb] Add pc check for thread-step-by-bp algorithms (#108504)

lldb-server built with NativeProcessLinux.cpp and
NativeProcessFreeBSD.cpp can use breakpoints to implement instruction
stepping on cores where there is no native instruction-step primitive.
Currently these set a breakpoint, continue, and if we hit the breakpoint
with the original thread, set the stop reason to be "trace".

I am wrapping up a change to lldb's breakpoint algorithm where I change
its current behavior of

"if a thread stops at a breakpoint site, we set
the thread's stop reason to breakpoint-hit, even if the breakpoint
hasn't been executed" +
"when resuming any thread at a breakpoint site, instruction-step past
the breakpoint before resuming"

to a behavior of

"when a thread executes a breakpoint, set the stop reason to
breakpoint-hit" +
"when a thread has hit a breakpoint, when the thread resumes, we
silently step past the breakpoint and then resume the thread".

For these lldb-server targets doing breakpoint stepping, this means that
if we are sitting on a breakpoint that has not yet executed, and
instruction-step the thread, we will execute the breakpoint instruction
at $pc (instead of $next-pc where it meant to go), and stop again -- at
the same pc value. Then we will rewrite the stop reason to 'trace'. The
higher level logic will see that we haven't hit the breakpoint
instruction again, so it will try to instruction step again, hitting the
breakpoint again forever.

To fix this, I'm checking that the thread matches the one we are
instruction-stepping-by-breakpoint AND that we've stopped at the
breakpoint address we are stepping to. Only in that case will the stop
reason be rewritten to "trace" hiding the implementation detail that the
step was done by breakpoints.



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