From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13769 invoked by alias); 29 Apr 2004 17:58:18 -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 13762 invoked from network); 29 Apr 2004 17:58:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 29 Apr 2004 17:58:17 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3THwGKG011671 for ; Thu, 29 Apr 2004 13:58:16 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3THwEw05386; Thu, 29 Apr 2004 13:58:14 -0400 Received: from redhat.com (dhcp-172-16-25-160.sfbay.redhat.com [172.16.25.160]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i3THwDC29710; Thu, 29 Apr 2004 10:58:13 -0700 Message-ID: <40914235.2040702@redhat.com> Date: Thu, 29 Apr 2004 17:58:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.2) Gecko/20040301 MIME-Version: 1.0 To: Andrew Cagney CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com, cagney 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> <409025F2.9080704@gnu.org> <20040429031240.GA12518@nevyn.them.org> <409105C7.1020502@gnu.org> In-Reply-To: <409105C7.1020502@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RedHat-Spam-Score: 0 X-SW-Source: 2004-04/txt/msg00685.txt.bz2 Andrew Cagney wrote: >> On Wed, Apr 28, 2004 at 05:45:22PM -0400, Andrew Cagney wrote: >> >>>>> >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 > > > >= 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; >> >> >> >> Would you mind clarifying the reason for having mips_regsize, which is >> used in a number of other places, return a regsize based on the ISA? > > > Hasn't this all come up before? > > It's the register size of the underlying ISA, on top of which the ABI is > implemented. I think I'll rename mips_regsize and mips_saved_regsize to > clarify this. > >> This change to mips_register_type conveys the fact that we've only got >> 32 bits of data. But we'll choose to print (in info registers) a >> 64-bit wide field for each GPR if the binary is tagged E_MIPS_ARCH_64 | >> E_MIPS_ABI_EABI32, and a 32-bit field if it's tagged E_MIPS_ARCH_2 | >> E_MIPS_ABI_EABI32. Conceptually, I think we're interested in some >> combination of the available register size (-> a property of the target) >> and the size of registers known to the inferior program (-> unclear mix >> of its ABI and ISA). > > > It does? With the above it should always print a 32-bit GPR reflecting > the 32-bit ABI. If you think it should display something else, look at > user-regs which lets you implement registers using the frame register > values (something psuedo registers can't handle). I've got a build -- I'll try your patch and let you know how it behaves. Are there any particular things you'd like me to check (eg. info reg), aside from the problem that got me on this in the first place?