On 2/3/25 06:50, Mikael Szreder wrote:
The gdbstub implementation for the Sparc architecture would incorectly
calculate the the floating point register offset.
This would cause register pairs(eg f32,f33) to point to the same value.
Fixes: 30038fd81808 ("target-sparc: Change fpr representation to doubles.")
Signed-off-by: Mikael Szreder <g...@miszr.win>
---
target/sparc/gdbstub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/sparc/gdbstub.c b/target/sparc/gdbstub.c
index ec0036e9ef..5578fa9813 100644
--- a/target/sparc/gdbstub.c
+++ b/target/sparc/gdbstub.c
@@ -80,7 +80,7 @@ int sparc_cpu_gdb_read_register(CPUState *cs, GByteArray
*mem_buf, int n)
}
if (n < 80) {
/* f32-f62 (double width, even numbers only) */
- return gdb_get_reg64(mem_buf, env->fpr[(n - 32) / 2].ll);
+ return gdb_get_reg64(mem_buf, env->fpr[(n - 64) + 16].ll);
I don't understand your issue with f33, since there is no such thing. Sparc v9 has f0,
f1, ... f31, then f32, f34, ... f62. The odd numbers above 32 do not exist.
Certainly the indexing is incorrect afterward.
Originally,
f32 = 64 -> (64 - 32) / 2 = 16
f34 = 66 -> (66 - 32) / 2 = 17
whereas your replacement gives
f34 = 66 -> (66 - 64) + 16 = 18.
One could rewrite this as
(n - 64) / 2 + 16
but that's algebraically identical to what we have now, so I don't see the
point.
One plausible adjustment in this area would be to reject odd numbers from this block and
let them fall through to 'return 0' at the end.
r~
