This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Rewrite data cache and use for stack access.
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