Hello,
on current master (d8a9d97317d03190b34498741f98f22e2a9afe3e), the basic
gdb stub test fails for ppc-linux-user when running "make check-tcg".
The error message is as follows:
TEST basic gdbstub support on ppc
Python Exception <class 'gdb.error'>: Could not fetch register "fpscr";
remote failure reply '14'
Error occurred in Python: Could not fetch register "fpscr"; remote failure
reply '14'
qemu-ppc: QEMU: Terminated via GDBstub
I've tested from a clean checkout with the following commands:
./configure --target-list=ppc-linux-user
make -j$(nproc) all
make check-tcg
According to git bisect, the test started failing with commit
1ec0fbe2ddadf17f7e0644b441833f0cd20dc137, which reduced
cc->gdb_num_core_regs from 71 to 70 (link to the patch on the mailing
list: https://lists.nongnu.org/archive/html/qemu-ppc/2026-02/msg00265.html).
Commit 7ddd3aca5f2efcf6aae10f836011e445ee77a6e1 (mailing list link:
https://lists.nongnu.org/archive/html/qemu-ppc/2026-02/msg00267.html)
got rid of the hardcoded value for cc->gdb_num_core_regs, but the test
still fails (people involved in the original patches in CC).
I've debugged around a bit but I don't know my way around the gdbstub
internals enough to propose a patch right away, so I'll just summarize
what I figured out so far.
1. Due to cc->gdb_num_core_regs not being set explicitly anymore, it is
set to 0 at the end of gdbstub/gdbstub.c:gdb_init_cpu(). In the same
function, cpu->gdb_num_regs gets set to 70.
2. When the test tries to read a register in
gdbstub/gdbstub.c:gdb_read_register(),
the first condition of "reg < cc->gdb_num_core_regs" is always false.
Also, the register number for fpscr passed to the function is is 103,
and cpu->gdb_num_regs is also 103. If the register number is supposed
to be an index (as I understand it), this would indicate an
off-by-one error somewhere.
If you have some pointers on where to look / what to check out for
fixing this, I'll happily try to work on a patch. But I suppose that
somebody more experienced with this could probably fix this much faster
than I can.
Best regards,
Florian
