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