[Qemu-devel] sparc64 gdb

[Qemu-devel] sparc64 gdb

[Paul Brook]

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

[Qemu-devel] Re: sparc64 gdb

[Paul Brook]

> 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)

Argh. What I meant was:

  tmp = env->fpr[i] << 32;
  tmp |= env->fpr[i + 1];
  registers[i/2 + 32] = tswap64(tmp)

Paul

Re: [Qemu-devel] sparc64 gdb

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

> 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.

[-- Attachment #2: Type: text/html, Size: 1892 bytes --]

Re: [Qemu-devel] sparc64 gdb

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

I can confirm that native gdb64 talking to x86 Qemu gets incorrect double
float registers values, 32-bit looks fine.

[-- Attachment #2: Type: text/html, Size: 125 bytes --]