From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17474 invoked by alias); 25 Oct 2013 07:47:25 -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 17462 invoked by uid 89); 25 Oct 2013 07:47:24 -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-f182.google.com Received: from mail-ve0-f182.google.com (HELO mail-ve0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 25 Oct 2013 07:47:23 +0000 Received: by mail-ve0-f182.google.com with SMTP id c14so785301vea.13 for ; Fri, 25 Oct 2013 00:47:21 -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=u2XAtFmHiuKG1tToOUgbVn6j1yTQSNa4Yl2baVVADvE=; b=bctWd5fSWUJ+8JK7753yRXGRU9v35kj6UJONc6qNRMi+y0+whQG1g1bmrOoIW6hdg4 TaLXGfpNivyy68SMjBk2FtnJ0raeN5xJaCunicyhNkOrh3D7S3WdT5WGmcfCP3oEgK+4 3PQBhvlQmlqEJyt8NM966u8MCsl0hQJ2H7ADtOLy7aqS9wyxRfoqt10eHcF5IbXiOykO KIVMUaJFxY8OJ2DmmQU16tb9jeW2Q1S7M8k3fPV7K1e2Be3gHbsdMhETrr9nZrVTKc68 7kibdBqcxy+9XYhypTCiImVihPFmYFN3vIp3toHihlnV8q0iN7qVQHV561ccA9lk+VMq xHhw== X-Gm-Message-State: ALoCoQkjMjDlSOjIHcrBb2yE92VA6Hn8VTdQRc/+gNFMOHe4HUGmNknSPf0hFlKzwySS6/+oZg6L343LwC3KhRl5kg+dfFoyZL1JR1LPliFsiOmLXfwIGaS/LJlV7xL67YSYzB95WHtmgAPbl3wqOrZvr8VwyGlxVUzcFkTSsYjXA5ku4fKxNewe/wr9NG+QcEcmqj1YZha9HCsfKLud0TNfZ2A2nbVQew== MIME-Version: 1.0 X-Received: by 10.52.34.109 with SMTP id y13mr3273380vdi.8.1382687241479; Fri, 25 Oct 2013 00:47:21 -0700 (PDT) Received: by 10.52.37.138 with HTTP; Fri, 25 Oct 2013 00:47:21 -0700 (PDT) In-Reply-To: <1382516855-32218-4-git-send-email-yao@codesourcery.com> References: <1382516855-32218-1-git-send-email-yao@codesourcery.com> <1382516855-32218-4-git-send-email-yao@codesourcery.com> Date: Fri, 25 Oct 2013 07:47: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/msg00785.txt.bz2 On Wed, Oct 23, 2013 at 1:27 AM, Yao Qi wrote: > Similar to stack cache, in this patch, we add > TARGET_OBJECT_CODE_MEMORY to read code from target and add a new > option "set code-cache on|off" to control use code cache or not. > > The invalidation of code cache is identical to stack cache, with this > patch, function target_dcache_invalidate invalidates both. Command > "set {stack,code}-cache" invalidates either of them. > > gdb: > > 2013-10-23 Yao Qi > > * target.c (struct target_dcache) : New field. > (target_dcache_alloc): Initialize field 'code'. > (set_stack_cache_enabled_p): Invalidate corresponding dcache. > (code_cache_enabled_p_1): New. > (code_cache_enabled_p): New. > (set_code_cache_enabled_p): New function. > (show_code_cache_enabled_p): New function. > (target_dcache_xfree): Free code cache. > (target_dcache_invalidate): Invalidate code cache. > (memory_xfer_partial_1): Handle TARGET_OBJECT_CODE_MEMORY and > code_cache_enabled_p. > (target_xfer_partial): Likewise. > (target_read_code): New function. > (initialize_targets): Register command. > * target.h (enum target_object) : New. > (target_read_code): Declare. > --- > gdb/target.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++-------- > gdb/target.h | 5 +++ > 2 files changed, 89 insertions(+), 13 deletions(-) > > diff --git a/gdb/target.c b/gdb/target.c > index 2ae42a8..624d41a 100644 > --- a/gdb/target.c > +++ b/gdb/target.c > @@ -218,6 +218,9 @@ struct target_dcache > /* Cache the memory on stack and areas specified by memory > attributes. */ > DCACHE *general; > + > + /* Cache the code. */ > + DCACHE *code; > }; While perhaps it usually won't be a problem (*1), it's odd to have two caches. If I do x/10x $addr and then x/10i $addr will both caches get populated? [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.] --- (*1): Because it's rarer to request reading areas of memory containing code vs disassembling it or reading prologues.