From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32763 invoked by alias); 23 May 2003 18:22:47 -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 15592 invoked from network); 23 May 2003 18:17:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 23 May 2003 18:17:16 -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 h4NIHGH00522 for ; Fri, 23 May 2003 14:17:16 -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 h4NIHGI16588; Fri, 23 May 2003 14:17:16 -0400 Received: from localhost.redhat.com (IDENT:aBQ+Ws/f+j7StFM9XJVf1gMEiP57qPAS@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4NIHFo18430; Fri, 23 May 2003 14:17:15 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id E3B602C43E; Fri, 23 May 2003 14:22:45 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16078.26357.742030.751293@localhost.redhat.com> Date: Fri, 23 May 2003 18:22:00 -0000 To: "Kris Warkentin" Cc: "Elena Zannoni" , , "Gdb@Sources.Redhat.Com" Subject: Re: assertion failure in regcache.c In-Reply-To: <11d801c32151$c37bbd80$0202040a@catdog> References: <0cd101c31fc1$b589c500$0202040a@catdog> <3ECCED6E.9060906@redhat.com> <0fb801c32095$785e5590$0202040a@catdog> <3ECD2378.1040704@redhat.com> <16077.19191.135513.118401@localhost.redhat.com> <11d801c32151$c37bbd80$0202040a@catdog> X-SW-Source: 2003-05/txt/msg00317.txt.bz2 Kris Warkentin writes: > > > 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. > > Well, I found the disagreement. It looks to me like > regcache->descr->register_offset[] is pointing to an upwardly growing list > of registers including the pseudo-registers. So you get something like dr5 > being 260 in the register_offset array but sh4_register_byte will return 124 > which would be the offset of fr10 (taking into account that dr0 is overlaid > on top of the fr regs). I'm inclined to think that the regcache way is > wrong since someone who updates dr0 and then reads fr0 will get conflicting > values. We shouldn't be storing extra copies of the same register. Looking at regcache.c I see that the long term goal is to not allocate space in the regcache for the PSEUDOs. But in the meantime, descr->register_offset[i] = REGISTER_BYTE (i); in the legacy init function, while descr->sizeof_register[i] = TYPE_LENGTH (descr->register_type[i]); descr->register_offset[i] = offset; offset += descr->sizeof_register[i]; in the new version of the function. So the mismatch seems to come from the TYPE_LENGTH() on the type of a pseudo, because that's always a positive quantity, while the REGISTER_BYTE points 'backwards'. Maybe we should be using the legacy version of the regcache init function? Is that doable? elena > > Where do I go from here? > > cheers, > > Kris