qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] sparc64 gdb


From: Paul Brook
Subject: [Qemu-devel] sparc64 gdb
Date: Fri, 13 Apr 2007 16:56:37 +0100
User-agent: KMail/1.9.5

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]