From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3738 invoked by alias); 28 Apr 2004 21:45:22 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3730 invoked from network); 28 Apr 2004 21:45:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 28 Apr 2004 21:45:21 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3SLjKKI032131 for ; Wed, 28 Apr 2004 17:45:21 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3SLjJv10016; Wed, 28 Apr 2004 17:45:19 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 335E92B9D; Wed, 28 Apr 2004 17:45:22 -0400 (EDT) Message-ID: <409025F2.9080704@gnu.org> Date: Wed, 28 Apr 2004 21:45:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Michael Snyder Cc: gdb-patches@sources.redhat.com, cagney , Daniel Jacobowitz Subject: Re: [RFA] mips 32/64 register/stack fix References: <408813A9.6000402@redhat.com> <4088242A.4070601@gnu.org> <40883C90.7030509@redhat.com> <40884155.2090205@gnu.org> <40884BEF.5070909@redhat.com> In-Reply-To: <40884BEF.5070909@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00648.txt.bz2 > Andrew Cagney wrote: > >>> #0 register_size (gdbarch=0x84093e8, regnum=120) >> >> >> >> 120 looks large enough to be cooked (but to confirm this can you look at "maint print raw-registers". This will also tell us the register's type, and hence confirm the size. > > > Yes, raw is from 0 to 89, and cooked is from 90 to 179. > regcache->descr->sizeof_register is as follows: > 8 for all raw > 8 for the first 70 cooked > 4 for the last 20 cooked > > register_type looks like: > raw: > 38 @ int64 > 32 @ double64 > 20 @ int64 > cooked: > 38 @ int64 > 32 @ double64 > 20 @ int32 good. >> Given that you see 8, this suggests that the register's type is wrong (see mips_register_type). > > > It looks to me as if mips_register_type relies on mips_regsize. > Which returns 8. Yep, and mips_register_type (120) returns int64_t. > > But mips_saved_regsize (tdep) returns 4 (as it should, I guess). > >> Also, what information is available in the object file header? > > > Can you be more specific? [...] > Here's your tdep info: > {elf_flags = 1610625025, mips_abi = MIPS_ABI_EABI32, I was looking to see if anything like that was present -> it is clearly identified as a 32-bit ABI binary. I think the bug is in mips_register_type, the tail end should probably be changed to read something like: else if (regnum >= NUM_REGS && gdbarch_tdep (gdbarch)->mips64_transfers_32bit_regs_p) /* The target, while using a 64-bit raw register buffer, is only transfering 32-bits of each integer register. Reflect this in the cooked/pseudo register value. */ return builtin_type_int32; else if (regnum > NUM_REGS && mips_saved_regsize (gdbarch) == 4) /* A 32-bit ABI such as o32 possibly running on a 64-bit ISA. */ return builtin_type_int32; else if (mips_regsize (gdbarch) == 8) /* 64-bit ISA. */ return builtin_type_int64; else /* 32-bit ISA. */ return builtin_type_int32; Andrew