From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16530 invoked by alias); 14 Oct 2002 17:45:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16521 invoked from network); 14 Oct 2002 17:45:57 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 14 Oct 2002 17:45:57 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 181ADh-00024f-00; Mon, 14 Oct 2002 13:45:38 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 1819Hw-0004iU-00; Mon, 14 Oct 2002 13:45:56 -0400 Date: Mon, 14 Oct 2002 10:45:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com, cagney@redhat.com Subject: Re: MIPS targets broken by dummy frame/regcache changes Message-ID: <20021014174556.GA17948@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com, cagney@redhat.com References: <20021010205112.GA26436@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021010205112.GA26436@nevyn.them.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00115.txt.bz2 On Thu, Oct 10, 2002 at 04:51:12PM -0400, Daniel Jacobowitz wrote: > I get this backtrace on MIPS/Linux: > #0 error (string=0x7591c4 "Unknowable register number %d.") > at /opt/src/gdb/src-gdblinks/gdb/utils.c:628 > #1 0x004f7fc8 in register_addr (regno=72, blockend=0) > at /opt/src/gdb/src-gdblinks/gdb/mips-linux-tdep.c:254 > #2 0x00575658 in store_register (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:440 > #3 0x005757e0 in store_inferior_registers (regno=72) at /opt/src/gdb/src-gdblinks/gdb/infptrace.c:470 > #4 0x004666f4 in legacy_write_register_gen (regnum=72, myaddr=0x1067cff8) > at /opt/src/gdb/src-gdblinks/gdb/regcache.c:838 > #5 0x00466cdc in write_register_gen (regnum=0, buf=0x0) > at /opt/src/gdb/src-gdblinks/gdb/regcache.c:903 > #6 0x00466f4c in write_register_bytes (myregstart=0, myaddr=0x1067ced8 "", inlen=0) > at /opt/src/gdb/src-gdblinks/gdb/regcache.c:950 > #7 0x004646e8 in regcache_cpy (dst=0x1006afc0, src=0x1022c5f8) > at /opt/src/gdb/src-gdblinks/gdb/regcache.c:350 > > The problem is that you're copying the whole regcache blindly. But there's > holes in it that we can't store. I'm sure you remember register 72 - it > used to be the frame pointer; now it's a hole in the register cache. We get > to it and try to write it, even though it doesn't exist. > > I get the same thing for the next couple registers, up to 89. For now I've > turned it down to a warning in my local tree... Found the real problem. It's my own fault for approving carelessly... Andrew, you checked in this to mips-linux-tdep.c: @@ -28,9 +29,7 @@ int mips_linux_cannot_fetch_register (int regno) { - if (regno >= FP_REGNUM) - return 1; - else if (regno == PS_REGNUM) + if (regno == PS_REGNUM) return 1; else if (regno == ZERO_REGNUM) return 1; @@ -41,9 +40,7 @@ mips_linux_cannot_fetch_register (int re int mips_linux_cannot_store_register (int regno) { - if (regno >= FP_REGNUM) - return 1; - else if (regno == PS_REGNUM) + if (regno == PS_REGNUM) return 1; else if (regno == ZERO_REGNUM) return 1; It's wrong. First of all, you changed the behavior for registers above FP_REGNUM, like UNUSED_REGNUM. Secondly, FP_REGNUM did not become OK to fetch/store after this patch. Just the numbering changed. I'll fix it in a little bit. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer