From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3884 invoked by alias); 22 May 2003 22:05:44 -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 3823 invoked from network); 22 May 2003 22:05:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 May 2003 22:05:43 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h4MM5gH26239 for ; Thu, 22 May 2003 18:05:42 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4MM5bI27691; Thu, 22 May 2003 18:05:37 -0400 Received: from localhost.redhat.com (IDENT:d2uKqR/Q/RWztnBhtT1HB/zKtcHPQ50D@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4MM5Zo00644; Thu, 22 May 2003 18:05:35 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 4E25A2C43D; Thu, 22 May 2003 18:11:03 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16077.19191.135513.118401@localhost.redhat.com> Date: Thu, 22 May 2003 22:05:00 -0000 To: kewarken@qnx.com Cc: cagney@redhat.com, "Gdb@Sources.Redhat.Com" Subject: Re: assertion failure in regcache.c In-Reply-To: <3ECD2378.1040704@redhat.com> References: <0cd101c31fc1$b589c500$0202040a@catdog> <3ECCED6E.9060906@redhat.com> <0fb801c32095$785e5590$0202040a@catdog> <3ECD2378.1040704@redhat.com> X-SW-Source: 2003-05/txt/msg00302.txt.bz2 Andrew Cagney writes: > > Looks like you're right. If I update to 2003-05-04 it's fine, but after > > that it blows up. Seems to only be a problem for sh4 though. Any > > suggestions as to what might be breaking this? Here's the output of maint > > print registers. > > > r0b1 51 51 204 4 int > > r1b1 52 52 208 4 int > > r2b1 53 53 212 4 int > > r3b1 54 54 216 4 int > > r4b1 55 55 220 4 int > > r5b1 56 56 224 4 int > > r6b1 57 57 228 4 int > > r7b1 58 58 232 4 int > > dr0 59 0 236*1 8 double > > dr2 60 1 244*1 8 double > > dr4 61 2 252*1 8 double > > dr6 62 3 260*1 8 double > > dr8 63 4 268*1 8 double > > dr10 64 5 276*1 8 double > > dr12 65 6 284*1 8 double > > dr14 66 7 292*1 8 double > > fv0 67 8 300*1 16 *2 > > fv4 68 9 316*1 16 *2 > > fv8 69 10 332*1 16 *2 > > fv12 70 11 348*1 16 *2 > > *1: Inconsistent register offsets. > > *2: Register type's name NULL. > > I'd start with the obvious thing - a simple tipo in the SH4 register > byte function. The code was written long before these sanity checks > were added and ``the old way'' makes it very hard to notice that the > values are skewed. > > Andrew > yes, look at sh_sh4_register_byte. Maybe FV0_REGNUM or FV_LAST_REGNUM are not set correctly or fv_reg_base_num does something wrong. These registers with (*1) are pseudo registers, so it's easy that the calculations could have been screwed up. elena