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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
