My understanding is that gdb considers sparc64 to have 48 "registers". The
first 32 are the same as sparc32, the last 16 (named f32, f34 ... f62) are
double precision registers. gdb then overlays this with d and q regs, but
we
don't need to care about that.
Quoting the V9 manual:
The FPU contains:
- 32 single-precision (32-bit) floating-point registers, numbered f[0],
f[1], .. f[31].
- 32 double-precision (64-bit) floating-point registers, numbered f[0],
f[2], .. f[62]
- 16 quad-precision (128-bit) floating-point registers, numbered f[0], f[4],
.. f[60].
The gdb remote protocol is defined to return register values in target byte
order. Currently we have the followingthe following:
for (i = 0; i < 64; i += 2) {
uint64_t tmp;
tmp = (uint64_t)tswap32(*((uint32_t *)&env->fpr[i])) << 32;
tmp |= tswap32(*((uint32_t *)&env->fpr[i + 1]));
registers[i/2 + 32] = tmp;
}
By my reading this get f0 and f1 the wrong way round on little-endian
hosts.
Should this be(omitting uint32 *casts for clarity):
tmp = env->fpr[i];
tmp |= env->fpr[i + 1];
registers[i/2 + 32] = tswap64(tmp)
Yes, something like that would be more correct.
