dlav-sc wrote: > Can you be specific here, what is the state of watchpoints for RISC-V? > Proposal, ratified, available in hardware, only available in simulation?
For context regarding the debug specification status: * The RISC-V debug specification 1.0 was ratified this April. * Both simulation (QEMU, Spike) and hardware support are currently available. * Linux support for the ptrace API is still pending. > See also hardware single stepping being missing for a while, but in that case > at least the software step is not user visible. So we could remove it once > the majority of hardware does support it. That specification also covers facilities for hardware-assisted single-stepping. But again, the relevant Linux-side support is missing at the moment. > If this were the only reason to have software watchpoints, I would be > hesitant to accept them if in a few years time RISC-V was going to have > hardware watchpoints anyway. Oh, I should probably be more accurate when describing the motivation. While it’s true that support for hardware-assisted watchpoints should be available in a year or so, there are still limitations: * The riscv specification itself is quite flexible, and there may be restrictions on the supported sizes that are tracked or constraints on memory references. * As mentioned above, hardware-assisted watchpoints track memory locations, while gdb allow setting software watchpoints on arbitrary expressions that may not reside in memory. gdb has facilities to handle this at the cost of performance. I think it’s up to the user to decide whether they’re willing to trade execution time for debugging convenience. Sometimes it may be acceptable, and sometimes not. If we provide users with clear indications (and settings) of what’s happening, this functionality can be quite useful. In addition to my thoughs I think gdb's documentation provides a `reason dtre` for them (https://sourceware.org/gdb/wiki/Internals%20Watchpoints): > * The watched memory region is too large for the underlying hardware > watchpoint support. For example, each x86 debug register can watch up to 4 > bytes of memory, so trying to watch data structures whose size is more than > 16 bytes will cause GDB to use software watchpoints. > * The value of the expression to be watched depends on data held in registers > (as opposed to memory). > * Too many different watchpoints requested. (On some architectures, this > situation is impossible to detect until the debugged program is resumed.) > Note that x86 debug registers are used both for hardware breakpoints and for > watchpoints, so setting too many hardware breakpoints might cause watchpoint > insertion to fail. > * No hardware-assisted watchpoints provided by the target implementation. https://github.com/llvm/llvm-project/pull/151195 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
