I'm currently reqriting bits of the qemu gdb stub to take advantage of new GDB
target description mechanisms, and have come accross what looks like a bug in
the sparc64 code.
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.
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)
?
My sparc64 machine takes several hours to boot, so help from someone with
knowledge and/or toolchains to test this would be appreciated.
Paul
