https://github.com/jasonmolenda commented:
Thanks for writing up the patch. We do see some handling of this behavior for x86 in lldb, e.g. ProcessWindowsNative, and KDP protocol support with x86 Darwin kernel debugging, also `breakpoint-pc-offset` in ProcessGDBRemote. But we do assume that the pc value reported by a thread that hit a breakpoint will be the start of the breakpoint instruction, not the end. The only question I have is -- if we are talking to a stub that supports `swbreak`/`hwbreak`, and we get a stop packet *without* those that hit a breakpoint, do we need to decr the pc value? I'm guessing gdbserver et al don't report a `reason:breakpoint` key-value pair in the stop packet. Should we treat the presence of `swbreak` or `hwbreak` as equivalent to receiving a `reason:breakpoint` in the packet (see the `reason` argument passed to `ProcessGDBRemote::SetThreadStopInfo`) to unambiguously indicate that a breakpoint was hit by this thread? https://github.com/llvm/llvm-project/pull/102873 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
