[Lldb-commits] [lldb] [lldb] Change lldb's breakpoint handling behavior (PR #96260)

[Pavel Labath via lldb-commits]

labath wrote:

> I haven't found the mechanism that an armv7 lldb-server would report `reason:trace` when it emulated the current instruction, put a breakpoint on the next instruction we'll execute, and 'continued' the thread when we resume. But I might have just missed something in ProcessNativeLinux where it knows it was instruction stepping. (but in the old stepping model in lldb, when you're at a BreakpointSite, the stop reason would be "breakpoint hit" even if it hadn't actually been hit)

I think that's this code here (I have missed it at first as well):
```
void NativeProcessLinux::MonitorBreakpoint(NativeThreadLinux &thread) {
  Log *log = GetLog(LLDBLog::Process | LLDBLog::Breakpoints);
  LLDB_LOG(log, "received breakpoint event, pid = {0}", thread.GetID());

  // Mark the thread as stopped at breakpoint.
  thread.SetStoppedByBreakpoint();
  FixupBreakpointPCAsNeeded(thread);

  if (m_threads_stepping_with_breakpoint.find(thread.GetID()) !=
      m_threads_stepping_with_breakpoint.end())
    thread.SetStoppedByTrace();

  StopRunningThreads(thread.GetID());
}
```

I think this is the correct thing to do, since lldb is completely unaware of whether software single stepping is taking place(*) I got lost in all of the mach exceptions, so it's not clear to me what is the conclusion. Are you saying that debugserver does not do this (i.e., it reports the stop as a "breakpoint hit", in the mach exception form)?

Just as a curiosity the linux kernel does allow you do use the hardware single step capability if debugging a 32 bit application on a 64-bit kernel (I'm not sure if the debugger process needs to be 64-bit or not). At one point, I wanted to make use of that, which would make our stepping behavior more reliable in these situations. However it would also make it harder to reproduce situations like these, as one would have to find actual 32-bit hardware...

(*) The code is probably too casual about this check though, in that it does not check whether it was the actual single-stepping breakpoint that got hit. If there was a breakpoint under the current PC, it would report this as "trace" even though it hasn't actually stepped anything. Could this maybe be the problem that you ran into with this patch?

https://github.com/llvm/llvm-project/pull/96260