From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9325 invoked by alias); 22 Apr 2004 22:49:24 -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 9317 invoked from network); 22 Apr 2004 22:49:24 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 Apr 2004 22:49:24 -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 i3MMnNKG001445 for ; Thu, 22 Apr 2004 18:49:23 -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 i3MMnKw12923; Thu, 22 Apr 2004 18:49:20 -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 i3MMnJC04586; Thu, 22 Apr 2004 15:49:20 -0700 Message-ID: <40884BEF.5070909@redhat.com> Date: Thu, 22 Apr 2004 22:49: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: 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> In-Reply-To: <40884155.2090205@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/msg00556.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 > 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 the bfd_arch_info: {bits_per_word = 64, bits_per_address = 64, bits_per_byte = 8, arch = bfd_arch_mips, mach = 64, arch_name = 0x8382960 "mips", printable_name = 0x8382a50 "mips:isa64", section_align_power = 3, the_default = 0, compatible = 0x82c36a4 , scan = 0x825f3c3 , next = 0x8382f00} Here's your tdep info: {elf_flags = 1610625025, mips_abi = MIPS_ABI_EABI32, found_abi = MIPS_ABI_EABI32, mips_fpu_type = MIPS_FPU_DOUBLE, mips_last_arg_regnum = 11, mips_last_fp_arg_regnum = 57, mips_default_saved_regsize = 4, mips_fp_register_double = 0, mips_default_stack_argsize = 4, default_mask_address_p = 0, mips64_transfers_32bit_regs_p = 0, regnum = 0x840968c, mips_processor_reg_names = 0x83995c0} (GDB) p /x tdep.elf_flags $10 = 0x60003001