From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30242 invoked by alias); 23 May 2003 20:29:29 -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 12523 invoked from network); 23 May 2003 20:21:13 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 23 May 2003 20:21:13 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id QAA13876; Fri, 23 May 2003 16:16:55 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA13014; Fri, 23 May 2003 16:21:13 -0400 Message-ID: <12a301c32168$de9e5660$0202040a@catdog> From: "Kris Warkentin" To: "Andrew Cagney" , "Elena Zannoni" Cc: "Gdb@Sources.Redhat.Com" 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> <16078.26357.742030.751293@localhost.redhat.com> <3ECE7AAE.7060308@redhat.com> Subject: Re: assertion failure in regcache.c Date: Fri, 23 May 2003 20:29:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-05/txt/msg00322.txt.bz2 Interesting. If I go through sh-tdep.c and comment out all the 'set_gdbarch_register_byte(blah)' calls, it works. Are there any potential negative implications of this or can we just trust regcache to do it's job? cheers, Kris ----- Original Message ----- From: "Andrew Cagney" To: "Elena Zannoni" ; "Kris Warkentin" Cc: "Gdb@Sources.Redhat.Com" Sent: Friday, May 23, 2003 3:46 PM Subject: Re: assertion failure in regcache.c > > 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. > > Plan B. Try not setting [deprecated_]register_byte. > > > 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? > > Are we all sitting comfortably? I'll try to explain the history to this > ... :-) > > Long ago, the code for reading/writing register values looked like (this > was burried in read_register_bytes): > > extract_integer (®isters[value->address], value->length); > > That is, given $dr5, gdb would create a value the location of which was > described by: > > location = lval_register; > regnum = $dr5 regnum > address = REGISTER_BYTE ($dr5 regnum) > > and then, assuming that the register cache was one big byte array, and > that the value was already in that array, and that they array only held > raw registers, use the ADDRESS and not the REGNUM to extract the value's > raw bytes. > > This forced the SH (and a few other architectures) to directly map > pseudo registers onto the raw register range (to guarentee that the > value read was always valid). > > Fortunatly, since then problems like this have (hopefully) all been > identified and fixed. It uses a read / modify / write to access the values: > > - map the [value->address, value->length) back to a sequence of > registers (identified by their register number). Here, they would be > pseudo registers > - read, using regcache_cooked_read, those registers and contatenate > them into a large buffer > - ``modify'' the bytes implied by [value->address, value->length) > - write, using regcache_cooked_write, each of the registers back into > the regcache > > The procedural interface means that something like $dr5 is always > constructed / updated on the fly (using the relevant raw registers), and > potential problems with out-dated register values are avoided. > > In the end, GDB doesn't store multiple values of the same register, but > it can end up caching the various values. That doesn't matter, GDB > flushes all such cached values after any target modify. > > enjoy, > Andrew > > >