From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18665 invoked by alias); 18 Jul 2003 22:20:56 -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 18658 invoked from network); 18 Jul 2003 22:20:55 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 18 Jul 2003 22:20:55 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6D8812B7F; Fri, 18 Jul 2003 18:20:54 -0400 (EDT) Message-ID: <3F1872C6.3040504@redhat.com> Date: Fri, 18 Jul 2003 22:20:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Watt Cc: gdb-patches@sources.redhat.com Subject: Re: [patch rfc] Add NUM_REGS pseudo regs to MIPS References: <200307072001.h67K1iMm054172@oberon.asicdesigners.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00350.txt.bz2 > Andrew Cagney wrote: > >> [ ... ] This adds NUM_REGS pseudo registers to the MIPS [ ... ] > > > OK, not a direct reply to your rfc, but it's in the right part of the > forest to be causing my problem, so... > > I've built a Linux cross MIPS toolchain from a combined source tree, > checked out of the sources.redhat.com tree yesterday (6 July), and when > I attempt to do anything in the sim with the register set, I hit an > assert: > > ../../combined/gdb/mips-tdep.c:5669: internal-error: mips_register_sim_regno: Assertion `regnum >= 0 && regnum < NUM_REGS' failed. > > Setting breakpoints and doing a nested gdb on the thing reveals that > it's trying to display register 90. The path there is kinda ugly, > but here's the trace into gdbarch_num_regs(), which is about to > return 90: Ok, I can see what is happening, but not why. For some reason mips_register_sim_regno is being called with a pseudo register value. I think that is just wrong. mips_pseudo_register_read/write should have converted that pseudo into a raw :-/ Unfortunatly the below backtrace doesn't explain why (notice how mips_register_sim_regno doesn't appear?). Run the gdb and when it internal errors, let it drop a core file, and then run gdb on that vis: gdb mips-linux-gnu-gdb core. Otherwize run gdb on gdb and set the breakpoint on `internal_error'. Andrew > #0 gdbarch_num_regs (gdbarch=0x82fdc48) at ../../combined/gdb/gdbarch.c:3077 > #1 0x080da346 in mips_print_registers_info (gdbarch=0x82fdc48, file=0x82fc890, > frame=0x82e0f40, regnum=-1, all=0) at ../../combined/gdb/mips-tdep.c:4345 > #2 0x080c9fb3 in gdbarch_print_registers_info (gdbarch=0x82fdc48, file=0x82fc890, > frame=0x82e0f40, regnum=-1, all=0) at ../../combined/gdb/gdbarch.c:4007 > #3 0x080b7e92 in registers_info (addr_exp=0x0, fpregs=0) > at ../../combined/gdb/infcmd.c:1620 > Here's what the gdbarch structure looks like (well, the first bits, anyhow): > > (top-gdb) print gdbarch > $8 = (struct gdbarch *) 0x82fdc48 > (top-gdb) print *gdbarch > $9 = {initialized_p = 1, bfd_arch_info = 0x8286740, byte_order = 0, > osabi = GDB_OSABI_UNKNOWN, tdep = 0x82fdc18, dump_tdep = 0x80dcc9c , > nr_data = 6, data = 0x82fded0, swap = 0x82fdef0, short_bit = 16, int_bit = 32, > long_bit = 32, long_long_bit = 64, float_bit = 32, double_bit = 64, > long_double_bit = 64, ptr_bit = 32, addr_bit = 32, bfd_vma_bit = 32, char_signed = 1, > read_pc = 0x80d53c8 , write_pc = 0x8095214 , > read_sp = 0x80d5204 , > virtual_frame_pointer = 0x80ce958 , > pseudo_register_read = 0x80d4aec , > pseudo_register_write = 0x80d4b78 , num_regs = 90, > num_pseudo_regs = 90, sp_regnum = -1, pc_regnum = -1, ps_regnum = -1, fp0_regnum = -1, > npc_regnum = -1, stab_reg_to_regnum = 0x80dbda4 , > ecoff_reg_to_regnum = 0x80dbe0c , > dwarf_reg_to_regnum = 0x80dbe0c , > sdb_reg_to_regnum = 0x80ce8a4 , > dwarf2_reg_to_regnum = 0x80dbe0c , > register_name = 0x80d48ec , > register_type = 0x80d5178 , deprecated_register_virtual_type = 0, > [ etc etc ] > > Being rather weak in gdb-fu, I thought I'd defer to an expert. Or at least someone > who's generated patches in the vicinity. > > If you'd like me to try some other stuff or provide more data, that can easily > be arranged.