From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16453 invoked by alias); 25 Oct 2013 15:57:39 -0000 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 Received: (qmail 16438 invoked by uid 89); 25 Oct 2013 15:57:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f172.google.com Received: from mail-ve0-f172.google.com (HELO mail-ve0-f172.google.com) (209.85.128.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 25 Oct 2013 15:57:37 +0000 Received: by mail-ve0-f172.google.com with SMTP id cz12so2868324veb.3 for ; Fri, 25 Oct 2013 08:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L8HJ0PFzY/2dHecgTgt8LPCkuq9WJ0AK/IvA7p0dGlU=; b=B1zKHTYXsOpIvR3WcVy53l0Pgj9Yrkq9xg3ddrqzERo+8X9XRCmHydZnIOuE5MX/Tt BAaP1KYxfViXzMgIy0C31E4BPgfmngcmSWLnP877l9V/UosOvwQiya/ww78o29/bUybu cIHPhAdPH75gR7NkzLIiWhJ87pSkDbDnLpUMRHeP3ETe6OQ1ozjYfSedKxX4z5Us0ZsF P2jA2PMhnGzCgXdTQNOqOFoVGtsZNV9QLDpHIpS2Wvryky6UAchaWV9NPYwsOyJL9RsQ 6dzOpq49aiN8INomGz9evM1jzZdXzUET5bTPkC3GHFnAwqIEFya1QJiy5cp1Le5YOCRw j5HQ== X-Gm-Message-State: ALoCoQlPMq3JM70OkyzN3V+UCtZ3s4Hf/fqmxuo34CvAJiUpmXJ6quu52P+CL/2LPyXXL+VeVF0oiu0aggERVeyp+rafRgShiEA8+8Zkrscja5RPi/FTSlOs1yeqHdbeapad+31doTmUfdyNOEmHR8hQTAJdC/9Is/EFlYYdQN+GgY53T6NV0LOQv89fDS4i+rn+FAv6BO4ooJ4IH+hQ0dJnVJ7WIC5oTg== MIME-Version: 1.0 X-Received: by 10.220.142.140 with SMTP id q12mr5191841vcu.21.1382716654894; Fri, 25 Oct 2013 08:57:34 -0700 (PDT) Received: by 10.52.37.138 with HTTP; Fri, 25 Oct 2013 08:57:34 -0700 (PDT) In-Reply-To: <526A8164.7040509@codesourcery.com> References: <1382516855-32218-1-git-send-email-yao@codesourcery.com> <1382516855-32218-4-git-send-email-yao@codesourcery.com> <526A8164.7040509@codesourcery.com> Date: Fri, 25 Oct 2013 15:57:00 -0000 Message-ID: Subject: Re: [PATCH 3/5] set/show code-cache From: Doug Evans To: Yao Qi Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00802.txt.bz2 On Fri, Oct 25, 2013 at 7:34 AM, Yao Qi wrote: > On 10/25/2013 03:47 PM, Doug Evans wrote: >> >> While perhaps it usually won't be a problem (*1), it's odd to have two >> caches. > > > At the very beginning, I use single dcache for both stack access and code > access. However, it is odd that command "set stack-cache off" invalidates > code caches, so I decide to add a new cache dedicated to code access. If it's just that "set stack-cache off" flushed the cache (as opposed to disabling/breaking all future use) I think that's ok. How often will it get turned on and off? >> If I do x/10x $addr and then x/10i $addr will both caches get populated? > > > No, "x/10i $addr" gets code cache populated, while "x/10x $addr" doesn't get > "general" or "stack" cache populated, unless I set memory attribute cache > for this area. Sorry, I left the assumption that caching is turned on via memory attributes as implicit. To be explicit: "If I turn on caching by memory attributes, and then do x/10x $addr and then x/10i $addr, will both caches get populated?" :) [Of course, if caching of the addresses in question is turned on by memory attributes then one doesn't need special code caching, but I'm not arguing against special support for code caching.] >> [Will there be latent bugs due to "storing the same thing twice"? >> (which has been a source of bugs in gdb) Plus there's the extra >> complexity of keeping both in sync.] > > > "Storing the same thing twice" may introduce bugs, but "store two things > together" is not good either :). It's still the same data. > The code keeping caches in sync is localized, and probably we can move them > into a new file target-cache.c. I don't see too much complexity here and > the disassembly is sped up, so it is worth doing it, IMO. It still seems to me to be an unnecessary complexity.