On 2026/10/06 23:31, Marc-André Lureau wrote:
Hi Akihiko
On Thu, Oct 1, 2026 at 12:03 PM Akihiko Odaki
<[email protected]> wrote:
On 2026/10/01 2:18, Philippe Mathieu-Daudé wrote:
Cc'ing Akihiko who worked on gdbstub.
On 11/9/26 14:27, Marc-André Lureau wrote:
Hi,
HMP monitor supports printing $register expression. The lookup
was done via GDB stub registers, and supplementary MonitorDef
HMP-specific tables.
Migrate HMP registers to use the GDB infrastructure and remove the
legacy HMP MonitorDef. Use a "qemu-debug" register group, as they are
aliases or synthetic registers, but gdb doesn't seem to care.
Unfortunately, these aliases and synthetic registers appear to have
several problems:
- GDB already provides writable pseudo-registers for SPARC64's asi and
pstate. The new QEMU registers shadow them but ignore writes, breaking
previously supported functionality. See:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/sparc64-tdep.c;h=93db3417a2a9f64790acab33288eb05764112e0b;hb=6a5e5259790e5a854ddbb69eb486b9245fcfeee8#l976
- GDB caches each raw register independently. Updating one alias can
leave another stale, causing incorrect reads or skipped writes.
- The new raw aliases do not inherit the original registers' unwind
rules, leading to incorrect register values when selecting older
call frames.
The latter two issues also affect the RISC-V aliases and cannot be
resolved merely by changing QEMU's register read/write callbacks. I
therefore think we need to retain HMP-specific handling for these aliases.
Thanks for the feedback and findings! Would it be an option to have
qemu/pseudo registers use a prefixed name like "qemu.", then it
shouldn't conflict with GDB. HMP would need to try with it if not
found. Wdyt?
That would avoid the conflict, but "info registers" in GDB would then
list these extra registers. This makes the output noisier, and the
displayed values could still be misleading or inaccurate.
Alternatively, keep the monitor specific register lookup, as a secondary path.
Ultimately, the design trade-off comes down to:
- The actual impact of exposing pseudo-registers via gdbstub.
- The relative complexity of implementing pseudo-registers versus
keeping a monitor-specific lookup as a fallback.
While the issues with pseudo-registers aren't critical, intuitively,
keeping the monitor-specific lookup as a fallback seems like it wouldn't
add much complexity, and might even be simpler. If so, I think keeping
the monitor-specific lookup is the better approach. Otherwise, we may
need to give this further consideration.
Regards,
Akihiko Odaki
