This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Failures in store.exp caused by regcache
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