Hi Florian,

On Fri, 27 Feb 2026 at 09:28, Florian Hofhammer
<[email protected]> wrote:
>
> Hello,
>
> on current master (d8a9d97317d03190b34498741f98f22e2a9afe3e), the basic
> gdb stub test fails for ppc-linux-user when running "make check-tcg".

Sorry for that :/

> 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

It's odd this config isn't caught by our CI.

> 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.

I'll have a look.

Regards,

Phil.

>
> Best regards,
> Florian

Reply via email to