From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Received: (qmail 17373 invoked from network); 9 Jan 2003 17:48:39 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 9 Jan 2003 17:48:39 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 54A7E3EC2; Thu, 9 Jan 2003 12:48:29 -0500 (EST) Message-ID: <3E1DB5ED.3060308@redhat.com> Date: Thu, 09 Jan 2003 17:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Failures in store.exp caused by regcache References: <20030108190506.GA558@nevyn.them.org> <3E1C77B4.8070401@redhat.com> <20030109032346.GA10532@nevyn.them.org> <3E1DA834.5060906@redhat.com> <20030109171414.GA26304@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00141.txt.bz2 > Makes sense. If this ever gets to be a problem (I'm not sure people > won't find creative ways to make a mockery of that "never" :) we can be > cleverer then. Like Apple? They, I believe, currently hold the award for the worst case senario. Due to objective C, the code does repeated inferior function calls from more outer frames. This causes GDB to constantly rebuild the frame cache. Can't see anyone doing worse than that, however, yes, never say never :-) >> >We obviously want to preserve things like the selected frame, however. > >> >> I'm actually a bit puzzled. I recently fixed a case and added a >> testcase (store.exp) that handles stores. Look for frame_find_by_id() >> in valops.c. > > > Yes. On GCC 2.95 that test shows failures still - different > optimization. Thanks for pointing me at your change; I see the problem > now. You only added the flush for the lval_register case. This is an > lval_memory, for all that it's in the frame cache. Slightly different > problem, same general solution. Instead of flush frames, flush dcache, flush registers. I think there should only be a generic target_changed(). > Something to think about: theoretically, any call to write_memory can > cause the frame cache to become out of date. For now I'll just move > the flushing within value_assign; but long-term I think it might be > generally worthwhile to have better information on when the cache needs > to be flushed, so that we can do it from within functions that modify > the target. It would mean something like a list of memory locations > read in the process of building the frame cache. Even per frame so > that we don't need to flush the whole thing. A single write to a single register/memory can completly change the entire target - consider a store to the page table base register. > Yeah, the complexity's gross; but there's a whole class of bugs here... This is a real case of `show us the money'. Compared to single step, there is no money in trying to make target writes faster. There is, however, plenty of return on being dumb - coherency problem - flush all caches - bug fixed. Compare the single step performance of Insight with Eclipse and Project Builder. Eclipe is a slow, not because of GDB or MI but because Eclipse hasn't yet focused on the important case - single step and handling that efficiently. > I decided "it should put you in main". That's what the comment above > is for. It's a kind of arbitrary decision but it was the most > consistent thing I could come up with. M'kay. Andrew