================ @@ -2332,6 +2332,12 @@ class Process : public std::enable_shared_from_this<Process>, Status ClearBreakpointSiteByID(lldb::user_id_t break_id); + /// Check if this process reports the original opcodes when memory is read + /// around a breakpoint site. Some debuggers/stubs can provide the original + /// instruction bytes that were replaced by the breakpoint trap. If false, + /// LLDB will attempt to perform the opcode substitution itself. ---------------- DavidSpickett wrote:
"attempt to" - are there situations where we would not know what to do? Hmm. Even when a breakpoint is external, we did request either hardware or software. So we know whether we should attempt a substitution. That's the first question answered. Quoting from the remote protocol spec: > A software breakpoint is implemented by replacing the instruction at addr > with a software breakpoint or trap instruction. The kind is target-specific > and typically indicates the size of the breakpoint in bytes that should be > inserted. E.g., the ARM and MIPS can insert either a 2 or 4 byte breakpoint. > Some architectures have additional meanings for kind (see > [Architecture-Specific Protocol > Details](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Architecture_002dSpecific-Protocol-Details.html#Architecture_002dSpecific-Protocol-Details)); > if no architecture-specific value is being used, it should be ‘0’. kind is > hex-encoded. So we also know what size we asked for. 99% of the time anyway. I expect if we do send kind zero, it's because it's a fixed sized ISA. In theory a stub could have some strange way of implementing this where they don't actually replace the instruction. For example if you had instruction bundles you might "break" the first part of the bundle. I suppose that again if we know the ISA, we would also know how software breaks generally worked there. So we could handle that. (this is why I would prefer the stubs to handle this themselves if possible) ...which is all to say "attempt to" is fine for now but it hints at problems we should consider. https://github.com/llvm/llvm-project/pull/201176 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
