From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HcOD0-00023h-Ss
	for qemu-devel@nongnu.org; Fri, 13 Apr 2007 12:01:11 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HcOCz-0001zS-GB
	for qemu-devel@nongnu.org; Fri, 13 Apr 2007 12:01:10 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HcOCy-0001yp-QR
	for qemu-devel@nongnu.org; Fri, 13 Apr 2007 12:01:08 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1HcO8g-0002b4-CC
	for qemu-devel@nongnu.org; Fri, 13 Apr 2007 11:56:42 -0400
From: Paul Brook <paul@codesourcery.com>
Date: Fri, 13 Apr 2007 16:56:37 +0100
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200704131656.38397.paul@codesourcery.com>
Subject: [Qemu-devel] sparc64 gdb
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

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