Re: [RFA] Rewrite data cache and use for stack access.

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jun 30, 2009 at 02:16:09PM -0700, Jacob Potter wrote:
> > * I'd find it helpful if any performance improvements were separated
> > out from stack caching.  Could you do that?
> >
> 
> I've split it into two patch files. Should I be submitting them as
> completely separate [RFA]s?

Yes, please - this just simplifies review.

> > * Have you thought at all about non-stop or multi-process debugging?
> > If we have a data cache which is specifically for stack accesses,
> > maybe we should associate it with the thread.
> 
> I don't think we need to associate the cache with a particular thread,
> since the threads' stacks will be in separate parts of the address
> space anyway; multiple caches will just add more stuff to keep track
> of.

You're right - but multi-process is another story; a memory address
requires a process context.

> For non-stop debugging, it seems like the correct thing to do would be
> to clear the cache between each _command_ the user gives. It's
> conceivable that a running thread might modify a value on a stopped
> thread's stack, and we don't want to hide that by keeping the cache
> between two backtrace commands. This may already happen; I'll double
> check.

Is this really necessary?  It defeats a lot of the benefit of the
caching, I'd think.

> > * We'd prefer that new functions take a target_ops; are the
> > current_target versions of read_stack and target_stack necessary?
> 
> They're called from value_at, which doesn't seem to get information
> about the target; is there a way to avoid using current_target there?

There probably isn't.  Let's push the use of current_target up into the
call site, instead of creating more 'bad' callees.

-- 
Daniel Jacobowitz
CodeSourcery