Re: Failures in store.exp caused by regcache

[Andrew Cagney <ac131313@redhat.com>]

> 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