From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28799 invoked by alias); 18 Sep 2008 22:05:13 -0000 Received: (qmail 28781 invoked by uid 22791); 18 Sep 2008 22:05:12 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 Sep 2008 22:04:31 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id A61B810004; Thu, 18 Sep 2008 22:04:28 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 7C58E10003; Thu, 18 Sep 2008 22:04:28 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KgRbv-0000WD-LV; Thu, 18 Sep 2008 18:04:27 -0400 Date: Thu, 18 Sep 2008 22:05:00 -0000 From: Daniel Jacobowitz To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [RFA] dcache.c cleanup Message-ID: <20080918220427.GA1691@caradoc.them.org> Mail-Followup-To: Doug Evans , gdb-patches@sourceware.org References: <20080917214444.625B81C777F@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080917214444.625B81C777F@localhost> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes 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: 2008-09/txt/msg00395.txt.bz2 On Wed, Sep 17, 2008 at 02:44:44PM -0700, Doug Evans wrote: > IIRC, "set remotecache" isn't being removed to avoid breaking existing > scripts. It's not used for anything, so this patch marks it as deprecated, > and hopefully in a future release we can delete it. > [If folks want I can instead submit a patch that makes it useful again - > e.g. as an escape hatch in case caching isn't working, it would globally > override the mem attribute settings.] Just my two cents, but I think that the command is useful (even if currently broken) - before deprecating it we should have a good idea of what to replace it with. Maybe a non-target-specific command and make this a deprecated alias to it. Should we come up with a coherent picture of the different kinds of memory accesses GDB needs? This is something I've been thinking about on and off. Particular ideas: - When we are doing prologue analysis, we use symbols from the executable (either minimal or full symbols) to find function boundaries. Then we analyze forwards from there. In every case I can think of, this means that we should use the code as present in the executable. It's like trust-readonly-sections, but for only prologue analysis reads; the manual disassemble command would still show if any code had been corrupted. - When reading data from the stack for unwinding, we can reliably assume that the data is thread-specific and not volatile. So we should be able to cache it automatically, even without user instruction, until that thread resumes. This is like memory attributes, but only for stack unwinding. - If we have memory region descriptions, it's probably safe to assume that we have the stack described as RAM. This is like "set mem inaccessible-by-default", but only for stack unwinding. WDYT - do those make sense? > 2008-09-17 Doug Evans > > * dcache.c (state_chars): New static global. > (ENTRY_INVALID,ENTRY_VALID): Renamed from ENTRY_BAD,ENTRY_OK. > All uses updated. > (dcache_info): Print cache state as mnemonically useful letters instead > of magic numbers. > (_initialize_dcache): Mark "set remotecache" as deprecated. > * doc/gdb.texinfo (info dcache): Update. The changes other than to "set remotecache" look OK to me (remember that doc has its own ChangeLog). -- Daniel Jacobowitz CodeSourcery