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

[Jason Molenda via lldb-commits]

jasonmolenda wrote:


> > My question basically was: what is the stop-reply packet for a single step (vCont:s) operation on arm32?
> 
> ```
> b-remote.async>  <  26> send packet: $vCont;s:p365766.365766#12
> b-remote.async>  < 293> read packet: $T05thread:p365766.365766;name:test.o;threads:365766;thread-pcs:004004ea;00:01000000;01:84f4feff;02:8cf4feff;03:01000000;04:40f3feff;05:00000000;06:00000000;07:20f3feff;08:00000000;09:00000000;0a:c80f4100;0b:00000000;0c:a8f3feff;0d:20f3feff;0e:a5d5edf7;0f:ea044000;10:30008e00;reason:trace;#61
> ```

Thanks @DavidSpickett just to be sure, this is armv7 right, not AArch32?  lldb-server had to do the `vCont;s` as a hardware breakpoint != current-pc, but it reported the stop reason as `reason:trace` so lldb should be completely unaware of this.  I was sure we'd get back `reason:breakpoint` reflecting the underlying mechanism that was used to do the trace.

I looked a little at the riscv instruction emulation instruction-step that Emmmer <yjhdandan at 163.com> added circa 2022 and it has `NativeProcessLinux::Resume()` calling `NativeProcessSoftwareSingleStep::SetupSoftwareSingleStepping()` when the thread's resume state is eStateStepping, which inserts a breakpoint and continues.  I'd guess that this lldb-server would stop with a `reason:breakpoint` when it hits the breakpoint that was used.

I spoke briefly with Jim Ingham about this issue.  He wasn't opposed to the idea of the Thread's `TemporaryResumeState` not only holding eStateStepping, but we also hold the pc address that we started the step from.  

I should have an armv7 apple watch that I can try, let me see what debugserver's behavior looks like on there with instruction step.

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