[Qemu-devel] [PATCH 0/2] PPC GDB stub fixes

[Qemu-devel] [PATCH 0/2] PPC GDB stub fixes

[Nathan Froyd]

This short patch series fixes two issues with the PPC GDB stub support:
off-by-one errors in Altivec and SPE register read/write and a fix for
how many "core" registers we tell an XML-aware GDB that we have.

-Nathan

[Qemu-devel] [PATCH 1/2] Fix off-by-one errors for Altivec and SPE registers

[Nathan Froyd]

Altivec and SPE both have 34 registers in their register sets, not 35
with a missing register 32.

GDB would ask for register 32 of the Altivec (resp. SPE) registers and
the code would claim it had zero width.  The QEMU GDB stub code would
then return an E14 to GDB, which would complain about not being sure
whether p packets were supported or not.

Signed-off-by: Nathan Froyd <froydnj@codesourcery.com>
---
 target-ppc/translate_init.c |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 9127081..229bfdb 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -9368,11 +9368,11 @@ static int gdb_get_avr_reg(CPUState *env, uint8_t *mem_buf, int n)
 #endif
         return 16;
     }
-    if (n == 33) {
+    if (n == 32) {
         stl_p(mem_buf, env->vscr);
         return 4;
     }
-    if (n == 34) {
+    if (n == 33) {
         stl_p(mem_buf, (uint32_t)env->spr[SPR_VRSAVE]);
         return 4;
     }
@@ -9391,11 +9391,11 @@ static int gdb_set_avr_reg(CPUState *env, uint8_t *mem_buf, int n)
 #endif
         return 16;
     }
-    if (n == 33) {
+    if (n == 32) {
         env->vscr = ldl_p(mem_buf);
         return 4;
     }
-    if (n == 34) {
+    if (n == 33) {
         env->spr[SPR_VRSAVE] = (target_ulong)ldl_p(mem_buf);
         return 4;
     }
@@ -9412,11 +9412,11 @@ static int gdb_get_spe_reg(CPUState *env, uint8_t *mem_buf, int n)
 #endif
         return 4;
     }
-    if (n == 33) {
+    if (n == 32) {
         stq_p(mem_buf, env->spe_acc);
         return 8;
     }
-    if (n == 34) {
+    if (n == 33) {
         /* SPEFSCR not implemented */
         memset(mem_buf, 0, 4);
         return 4;
@@ -9436,11 +9436,11 @@ static int gdb_set_spe_reg(CPUState *env, uint8_t *mem_buf, int n)
 #endif
         return 4;
     }
-    if (n == 33) {
+    if (n == 32) {
         env->spe_acc = ldq_p(mem_buf);
         return 8;
     }
-    if (n == 34) {
+    if (n == 33) {
         /* SPEFSCR not implemented */
         return 4;
     }
-- 
1.6.0.5

[Qemu-devel] [PATCH 2/2] Work around QEMU GDB stub suboptimality

[Nathan Froyd]

The current XML files claim, on floating point-supporting Power chips,
that $f0 is register 70.  This would be fine, except that register 70
for non-XML-aware GDB is FPSCR.  More importantly, 70 is less than
NUM_CORE_REGS (71) for Power, so a request for register 70 goes to the
"core" register reading routines, rather than the floating-point
register read routine we registered with gdb_register_coprocessor.

Therefore, when we are talking to an XML-aware GDB, we claim that
register has zero width, which causes the rest of QEMU's GDB stub to
send an error back to GDB, which causes GDB to be unable to read the
floating-point registers.  (The problem is also present for SPE
registers and occurs in a slightly different way for Altivec registers.)

The best way to fix this is to have the "core register" XML files for
PPC32 and PPC64 claim that there is a 4-byte register 70, which causes
$f0 to be register 71, and everything works just fine from that point
forward.

Signed-off-by: Nathan Froyd <froydnj@codesourcery.com>
---
 gdb-xml/power-core.xml   |    9 +++++++++
 gdb-xml/power64-core.xml |    9 +++++++++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/gdb-xml/power-core.xml b/gdb-xml/power-core.xml
index 0c69e8c..dae13a6 100644
--- a/gdb-xml/power-core.xml
+++ b/gdb-xml/power-core.xml
@@ -46,4 +46,13 @@
   <reg name="lr" bitsize="32" type="code_ptr"/>
   <reg name="ctr" bitsize="32" type="uint32"/>
   <reg name="xer" bitsize="32" type="uint32"/>
+  <!-- HACK: The way the QEMU GDB stub code is currently written requires
+       the "integer" registers from the XML file to span the entirety of
+       NUM_CORE_REGS that non-XML-aware GDB requires.  Otherwise, XML-aware
+       GDB thinks that "coprocessor" registers from XML, such as the
+       floating-point registers, have register numbers less than
+       NUM_CORE_REGS.  This can lead to problems.  Work around it by using
+       an unnamed register as padding; NUM_CORE_REGS on Power is 71 and
+       this register is 70.  It would be fpscr for non-XML-aware GDB.  -->
+  <reg name="" bitsize="32" type="uint32"/>
 </feature>
diff --git a/gdb-xml/power64-core.xml b/gdb-xml/power64-core.xml
index 6cc1531..fef42e4 100644
--- a/gdb-xml/power64-core.xml
+++ b/gdb-xml/power64-core.xml
@@ -46,4 +46,13 @@
   <reg name="lr" bitsize="64" type="code_ptr"/>
   <reg name="ctr" bitsize="64" type="uint64"/>
   <reg name="xer" bitsize="32" type="uint32"/>
+  <!-- HACK: The way the QEMU GDB stub code is currently written requires
+       the "integer" registers from the XML file to span the entirety of
+       NUM_CORE_REGS that non-XML-aware GDB requires.  Otherwise, XML-aware
+       GDB thinks that "coprocessor" registers from XML, such as the
+       floating-point registers, have register numbers less than
+       NUM_CORE_REGS.  This can lead to problems.  Work around it by using
+       an unnamed register as padding; NUM_CORE_REGS on Power is 71 and
+       this register is 70.  It would be fpscr for non-XML-aware GDB.  -->
+  <reg name="" bitsize="32" type="uint32"/>
 </feature>
-- 
1.6.0.5

Re: [Qemu-devel] [PATCH 0/2] PPC GDB stub fixes

[Aurelien Jarno]

On Mon, Mar 02, 2009 at 05:58:39PM -0800, Nathan Froyd wrote:
> This short patch series fixes two issues with the PPC GDB stub support:
> off-by-one errors in Altivec and SPE register read/write and a fix for
> how many "core" registers we tell an XML-aware GDB that we have.
> 

Thanks, both applied.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net