From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25928 invoked by alias); 30 Jun 2009 21:16:21 -0000 Received: (qmail 25919 invoked by uid 22791); 30 Jun 2009 21:16:20 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Jun 2009 21:16:15 +0000 Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id n5ULGCov029144 for ; Tue, 30 Jun 2009 22:16:12 +0100 Received: from ewy10 (ewy10.prod.google.com [10.241.103.10]) by spaceape13.eur.corp.google.com with ESMTP id n5ULG9Fp016310 for ; Tue, 30 Jun 2009 14:16:10 -0700 Received: by ewy10 with SMTP id 10so594844ewy.0 for ; Tue, 30 Jun 2009 14:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.26.200 with SMTP id c50mr2626097wea.61.1246396569534; Tue, 30 Jun 2009 14:16:09 -0700 (PDT) In-Reply-To: <20090629193230.GA8840@caradoc.them.org> References: <7e6c8d660906291200r164b3c7l95376866122e86fb@mail.gmail.com> <20090629193230.GA8840@caradoc.them.org> Date: Tue, 30 Jun 2009 21:16:00 -0000 Message-ID: <7e6c8d660906301416k6fac6853k1d295bd5feae3283@mail.gmail.com> Subject: Re: [RFA] Rewrite data cache and use for stack access. From: Jacob Potter To: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00896.txt.bz2 On Mon, Jun 29, 2009 at 12:32 PM, Daniel Jacobowitz wrote: > > I think that part of the trouble with the existing cache is that it's > implemented too much like a cache. Rather than making it > set-associative, and thus (marginally?) less effective, what about > fixing the search to use a more efficient structure? > > What we have today is a linked list of blocks. If we put them into a > splay tree instead, search performance would be much better. It would > be very similar to addrmap.c's splay trees. > Interesting. I'll look into that... > > * 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? > * 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. 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. > * Do we really need an option to turn this off? It seems to me to be > risk-free; whether the target memory ends up volatile or not, we > don't want volatile semantics on saved registers anyway. > > * If we do add the option, it requires documentation. Whether we do > or not, please add an entry to NEWS about the new feature. I'd like to keep the option, "just in case"; perhaps it should default to on, though. > * 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? >> +extern struct value *value_at_lazy_stack (struct type *type, CORE_ADDR addr); > > IMO this one isn't needed; just call value_set_stack on the result > of value_at_lazy, right? Hmm, you're right. I'll change that. Next step: looking into using splay trees. - Jacob