[Qemu-devel] sparc64 gdb

[Paul Brook <paul@codesourcery.com>]

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