DavidSpickett wrote: Found it quite quickly: https://sourceware.org/gdb/wiki/Internals/Breakpoint%20Handling
> The field placed_address may be updated if the breakpoint was placed at a > related address; the field shadow_contents contains the real contents of the > bytes where the breakpoint has been inserted, **if reading memory would > return the breakpoint instead of the underlying memory;** Which sounds very mysterious but I think in reality GDB is substituting in the original instruction all the time. It's not looking for some feature from the stub, or otherwise fingerprinting it to see if it's OpenOCD, or looking for some Hardvard Architecture feature where a data fetch wouldn't return instructions. What is interesting though is that elsewhere it mentions writing to such memory. If you do that, you'd want the new instruction to go in the client side buffer, and to send the break instruction instead (assuming you can 100% know what instruction it's going to use). Writes might be orthogonal to your specific problem, but I want to check how LLDB handles this if at all before we commit to the changes in this PR. As it is on the same theme. (I suspect that it is not specified what a debug stub should do if asked to write memory that has a software break in it) https://github.com/llvm/llvm-project/pull/201176 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
