From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27518 invoked by alias); 21 Jul 2003 22:38:34 -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 27509 invoked from network); 21 Jul 2003 22:38:31 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 21 Jul 2003 22:38:31 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D86352B7F; Mon, 21 Jul 2003 18:07:59 -0400 (EDT) Message-ID: <3F1C643F.8090801@redhat.com> Date: Mon, 21 Jul 2003 22:38: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: <200307211820.h6LIKiIQ008125@oberon.asicdesigners.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2003-07/txt/msg00382.txt.bz2 > OK... cvs as of about 9:30PDT 21 July. Confirmed that the GDB build > was only -O -g, though some other things (newlib, mostly) got -O2. > > That was quite a tail-call optimization -- looks like 3 frames > vanished. I'm a little worried about a warning I got in this > backtrace from top-gdb: > During symbol reading, debug info mismatch between compiler and debugger. > > The top gdb and gcc came from RedHat 7.1. I suppose I could build a > new host gcc and gdb, but that seems like a fair amount of pain. > > Anyway, here's the trace, along with a bunch of "up; list" to make sure > everything's sane looking: Yep! > (top-gdb) info stack > #0 internal_error (file=0x824e580 "../../combined/gdb/mips-tdep.c", line=5671, > string=0x824e555 "%s: Assertion `%s' failed.") at ../../combined/gdb/utils.c:807 > #1 0x080dd45c in mips_register_sim_regno (regnum=90) > at ../../combined/gdb/mips-tdep.c:5671 > #2 0x080cb037 in gdbarch_register_sim_regno (gdbarch=0x83179d8, reg_nr=90) > at ../../combined/gdb/gdbarch.c:3983 > #3 0x08127e0f in gdbsim_fetch_register (regno=90) at ../../combined/gdb/remote-sim.c:299 > #4 0x08094450 in legacy_read_register_gen (regnum=90, > myaddr=0xbffff0f0 "Ððÿ¿Øy1\b\030ñÿ¿\020\227\f\bØy1\bZ") > at ../../combined/gdb/regcache.c:730 > #5 0x0809453e in regcache_raw_read (regcache=0x8323000, regnum=90, buf=0xbffff0f0) > at ../../combined/gdb/regcache.c:748 > #6 0x0809499a in regcache_cooked_read (regcache=0x8323000, regnum=90, buf=0xbffff0f0) > at ../../combined/gdb/regcache.c:838 It went wrong here. It tests (regnum < ->nr_raw_registers), but for legacy targets NR_RAW_REGISTERS == NUM_REGS + NUM_PSEUDO_REGS :-( The correct fix is to just delete a heap of code, however ... From regcache.c: > if ((!gdbarch_pseudo_register_read_p (gdbarch) > && !gdbarch_pseudo_register_write_p (gdbarch) > && !gdbarch_register_type_p (gdbarch)) > || REGISTER_BYTE_P () || REGISTER_RAW_SIZE_P ()) > { > descr->legacy_p = 1; > init_legacy_regcache_descr (gdbarch, descr); > return descr; > } can you try removing the two || ... clauses I added 2003-07-03? I think my change may have fixed some legacy code but broke others :-( Andrew