ppc-linux-user GDB stub broken

ppc-linux-user GDB stub broken

[Florian Hofhammer]

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

Re: ppc-linux-user GDB stub broken

[Philippe Mathieu-Daudé]

Hi Florian,

On Fri, 27 Feb 2026 at 09:28, Florian Hofhammer
<florian.hofhammer@fhofhammer.de> 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

Re: ppc-linux-user GDB stub broken

[Philippe Mathieu-Daudé]

On 27/2/26 10:58, Philippe Mathieu-Daudé wrote:
> Hi Florian,


>> on current master (d8a9d97317d03190b34498741f98f22e2a9afe3e), the basic
>> gdb stub test fails for ppc-linux-user when running "make check-tcg".


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

Short term, this seems to fix it:

-- >8 --
diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
index 90f4b95135b..0b0a5d1e044 100644
--- a/gdbstub/gdbstub.c
+++ b/gdbstub/gdbstub.c
@@ -610,6 +610,10 @@ void gdb_register_coprocessor(CPUState *cpu,
      guint i;
      int base_reg = cpu->gdb_num_regs;

+    if (g_pos && g_pos != base_reg) {
+        base_reg = g_pos;
+    }
+
      for (i = 0; i < cpu->gdb_regs->len; i++) {
          /* Check for duplicates.  */
          s = &g_array_index(cpu->gdb_regs, GDBRegisterState, i);
@@ -622,14 +626,7 @@ void gdb_register_coprocessor(CPUState *cpu,

      /* Add to end of list.  */
      cpu->gdb_num_regs += feature->num_regs;
-    if (g_pos) {
-        if (g_pos != base_reg) {
-            error_report("Error: Bad gdb register numbering for '%s', "
-                         "expected %d got %d", feature->xml, g_pos, 
base_reg);
-        } else {
-            cpu->gdb_num_g_regs = cpu->gdb_num_regs;
-        }
-    }
+    cpu->gdb_num_g_regs = cpu->gdb_num_regs;
  }

  void gdb_unregister_coprocessor_all(CPUState *cpu)
diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
index e0aae9c9eaf..51b14b95b9f 100644
--- a/target/ppc/gdbstub.c
+++ b/target/ppc/gdbstub.c
@@ -502,7 +502,7 @@ void ppc_gdb_init(CPUState *cs, PowerPCCPUClass *pcc)
  {
      if (pcc->insns_flags & PPC_FLOAT) {
          gdb_register_coprocessor(cs, gdb_get_float_reg, gdb_set_float_reg,
- 
gdb_find_static_feature("power-fpu.xml"), 0);
+ 
gdb_find_static_feature("power-fpu.xml"), 71);
      }
      if (pcc->insns_flags & PPC_ALTIVEC) {
          gdb_register_coprocessor(cs, gdb_get_avr_reg, gdb_set_avr_reg,

---

Re: ppc-linux-user GDB stub broken

[Alex Bennée]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 27/2/26 10:58, Philippe Mathieu-Daudé wrote:
>> Hi Florian,
>
>
>>> on current master (d8a9d97317d03190b34498741f98f22e2a9afe3e), the basic
>>> gdb stub test fails for ppc-linux-user when running "make check-tcg".
>
>
>>> 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.
>
> Short term, this seems to fix it:
>
> -- >8 --
> diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> index 90f4b95135b..0b0a5d1e044 100644
> --- a/gdbstub/gdbstub.c
> +++ b/gdbstub/gdbstub.c
> @@ -610,6 +610,10 @@ void gdb_register_coprocessor(CPUState *cpu,
>      guint i;
>      int base_reg = cpu->gdb_num_regs;
>
> +    if (g_pos && g_pos != base_reg) {
> +        base_reg = g_pos;
> +    }
> +
>      for (i = 0; i < cpu->gdb_regs->len; i++) {
>          /* Check for duplicates.  */
>          s = &g_array_index(cpu->gdb_regs, GDBRegisterState, i);
> @@ -622,14 +626,7 @@ void gdb_register_coprocessor(CPUState *cpu,
>
>      /* Add to end of list.  */
>      cpu->gdb_num_regs += feature->num_regs;
> -    if (g_pos) {
> -        if (g_pos != base_reg) {
> -            error_report("Error: Bad gdb register numbering for '%s', "
> -                         "expected %d got %d", feature->xml, g_pos,
>                           base_reg);
> -        } else {
> -            cpu->gdb_num_g_regs = cpu->gdb_num_regs;
> -        }
> -    }
> +    cpu->gdb_num_g_regs = cpu->gdb_num_regs;
>  }
>
>  void gdb_unregister_coprocessor_all(CPUState *cpu)
> diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
> index e0aae9c9eaf..51b14b95b9f 100644
> --- a/target/ppc/gdbstub.c
> +++ b/target/ppc/gdbstub.c
> @@ -502,7 +502,7 @@ void ppc_gdb_init(CPUState *cs, PowerPCCPUClass *pcc)
>  {
>      if (pcc->insns_flags & PPC_FLOAT) {
>          gdb_register_coprocessor(cs, gdb_get_float_reg, gdb_set_float_reg,
> - gdb_find_static_feature("power-fpu.xml"), 0);
> + gdb_find_static_feature("power-fpu.xml"), 71);
>      }
>      if (pcc->insns_flags & PPC_ALTIVEC) {
>          gdb_register_coprocessor(cs, gdb_get_avr_reg, gdb_set_avr_reg,
>
> ---

Tested-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: ppc-linux-user GDB stub broken

[Pierrick Bouvier]

On 2/27/26 1:58 AM, Philippe Mathieu-Daudé wrote:
>> 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.
>

https://gitlab.com/qemu-project/qemu/-/blob/master/tests/tcg/multiarch/Makefile.target#L153

```
ifneq ($(GDB),)
...
# gdbstub tests
...
else
run-gdbstub-%:
	$(call skip-test, "gdbstub test $*", "need working gdb with $(patsubst 
-%,,$(TARGET_NAME)) support")
```

Unfortunately, gdb is not installed in any container.

At least we caught something with this bug, which is great :).

Regards,
Pierrick

Re: ppc-linux-user GDB stub broken

[Pierrick Bouvier]

On 2/27/26 9:21 AM, Pierrick Bouvier wrote:
> On 2/27/26 1:58 AM, Philippe Mathieu-Daudé wrote:
>>> 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.
>>
> 
> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/tcg/multiarch/Makefile.target#L153
> 
> ```
> ifneq ($(GDB),)
> ...
> # gdbstub tests
> ...
> else
> run-gdbstub-%:
> 	$(call skip-test, "gdbstub test $*", "need working gdb with $(patsubst
> -%,,$(TARGET_NAME)) support")
> ```
> 
> Unfortunately, gdb is not installed in any container.
> 
> At least we caught something with this bug, which is great :).
> 
> Regards,
> Pierrick

Alex, is it something you could see to add to existing Dockerfiles?

Thanks,
Pierrick

Re: ppc-linux-user GDB stub broken

[Philippe Mathieu-Daudé]

On 27/2/26 14:09, Philippe Mathieu-Daudé wrote:
> On 27/2/26 10:58, Philippe Mathieu-Daudé wrote:
>> Hi Florian,
> 
> 
>>> on current master (d8a9d97317d03190b34498741f98f22e2a9afe3e), the basic
>>> gdb stub test fails for ppc-linux-user when running "make check-tcg".
> 
> 
>>> 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.
> 
> Short term, this seems to fix it:

Series for the generic fix posted:

https://lore.kernel.org/qemu-devel/20260227213958.21170-1-philmd@linaro.org/

> 
> -- >8 --
> diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> index 90f4b95135b..0b0a5d1e044 100644
> --- a/gdbstub/gdbstub.c
> +++ b/gdbstub/gdbstub.c
> @@ -610,6 +610,10 @@ void gdb_register_coprocessor(CPUState *cpu,
>       guint i;
>       int base_reg = cpu->gdb_num_regs;
> 
> +    if (g_pos && g_pos != base_reg) {
> +        base_reg = g_pos;
> +    }
> +
>       for (i = 0; i < cpu->gdb_regs->len; i++) {
>           /* Check for duplicates.  */
>           s = &g_array_index(cpu->gdb_regs, GDBRegisterState, i);
> @@ -622,14 +626,7 @@ void gdb_register_coprocessor(CPUState *cpu,
> 
>       /* Add to end of list.  */
>       cpu->gdb_num_regs += feature->num_regs;
> -    if (g_pos) {
> -        if (g_pos != base_reg) {
> -            error_report("Error: Bad gdb register numbering for '%s', "
> -                         "expected %d got %d", feature->xml, g_pos, 
> base_reg);
> -        } else {
> -            cpu->gdb_num_g_regs = cpu->gdb_num_regs;
> -        }
> -    }
> +    cpu->gdb_num_g_regs = cpu->gdb_num_regs;
>   }
> 
>   void gdb_unregister_coprocessor_all(CPUState *cpu)
> diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
> index e0aae9c9eaf..51b14b95b9f 100644
> --- a/target/ppc/gdbstub.c
> +++ b/target/ppc/gdbstub.c
> @@ -502,7 +502,7 @@ void ppc_gdb_init(CPUState *cs, PowerPCCPUClass *pcc)
>   {
>       if (pcc->insns_flags & PPC_FLOAT) {
>           gdb_register_coprocessor(cs, gdb_get_float_reg, 
> gdb_set_float_reg,
> - gdb_find_static_feature("power-fpu.xml"), 0);
> + gdb_find_static_feature("power-fpu.xml"), 71);
>       }
>       if (pcc->insns_flags & PPC_ALTIVEC) {
>           gdb_register_coprocessor(cs, gdb_get_avr_reg, gdb_set_avr_reg,
> 
> ---

Re: ppc-linux-user GDB stub broken

[Pierrick Bouvier]

On 2/27/26 1:40 PM, Philippe Mathieu-Daudé wrote:
> On 27/2/26 14:09, Philippe Mathieu-Daudé wrote:
>> On 27/2/26 10:58, Philippe Mathieu-Daudé wrote:
>>> Hi Florian,
>>
>>
>>>> on current master (d8a9d97317d03190b34498741f98f22e2a9afe3e), the basic
>>>> gdb stub test fails for ppc-linux-user when running "make check-tcg".
>>
>>
>>>> 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.
>>
>> Short term, this seems to fix it:
> 
> Series for the generic fix posted:
> 
> https://lore.kernel.org/qemu-devel/20260227213958.21170-1-philmd@linaro.org/
>

Broken link, and unknown series.
Can you send the good one?

Regards,
Pierrick

Re: ppc-linux-user GDB stub broken

[Pierrick Bouvier]

On 2/27/26 1:43 PM, Pierrick Bouvier wrote:
> On 2/27/26 1:40 PM, Philippe Mathieu-Daudé wrote:
>> On 27/2/26 14:09, Philippe Mathieu-Daudé wrote:
>>> On 27/2/26 10:58, Philippe Mathieu-Daudé wrote:
>>>> Hi Florian,
>>>
>>>
>>>>> on current master (d8a9d97317d03190b34498741f98f22e2a9afe3e), the basic
>>>>> gdb stub test fails for ppc-linux-user when running "make check-tcg".
>>>
>>>
>>>>> 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.
>>>
>>> Short term, this seems to fix it:
>>
>> Series for the generic fix posted:
>>
>> https://lore.kernel.org/qemu-devel/20260227213958.21170-1-philmd@linaro.org/
>>
> 
> Broken link, and unknown series.
> Can you send the good one?
>

Oops, was just a lore.kernel.org delay.

> Regards,
> Pierrick

Re: ppc-linux-user GDB stub broken

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:

> On 2/27/26 9:21 AM, Pierrick Bouvier wrote:
>> On 2/27/26 1:58 AM, Philippe Mathieu-Daudé wrote:
>>>> 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.
>>>
>> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/tcg/multiarch/Makefile.target#L153
>> ```
>> ifneq ($(GDB),)
>> ...
>> # gdbstub tests
>> ...
>> else
>> run-gdbstub-%:
>> 	$(call skip-test, "gdbstub test $*", "need working gdb with $(patsubst
>> -%,,$(TARGET_NAME)) support")
>> ```
>> Unfortunately, gdb is not installed in any container.
>> At least we caught something with this bug, which is great :).
>> Regards,
>> Pierrick
>
> Alex, is it something you could see to add to existing Dockerfiles?

I think we need to work out the equivalent of gdb-multiarch and add
mappings to the libvirt-ci project. But for linux-all-test-cross we can
add it manually.

>
> Thanks,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: ppc-linux-user GDB stub broken

[Pierrick Bouvier]

On 2/28/26 9:53 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
> 
>> On 2/27/26 9:21 AM, Pierrick Bouvier wrote:
>>> On 2/27/26 1:58 AM, Philippe Mathieu-Daudé wrote:
>>>>> 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.
>>>>
>>> https://gitlab.com/qemu-project/qemu/-/blob/master/tests/tcg/multiarch/Makefile.target#L153
>>> ```
>>> ifneq ($(GDB),)
>>> ...
>>> # gdbstub tests
>>> ...
>>> else
>>> run-gdbstub-%:
>>> 	$(call skip-test, "gdbstub test $*", "need working gdb with $(patsubst
>>> -%,,$(TARGET_NAME)) support")
>>> ```
>>> Unfortunately, gdb is not installed in any container.
>>> At least we caught something with this bug, which is great :).
>>> Regards,
>>> Pierrick
>>
>> Alex, is it something you could see to add to existing Dockerfiles?
> 
> I think we need to work out the equivalent of gdb-multiarch and add
> mappings to the libvirt-ci project. But for linux-all-test-cross we can
> add it manually.
> 

Yes, it sounds good, it should be enough to get it in build-user and 
build-user-static jobs.
I asked you because I know you already contributed to lcitool and did 
such an update, so it should be easier than for me.

Thanks,
Pierrick