From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7128 invoked by alias); 19 May 2014 17:44:03 -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 7092 invoked by uid 89); 19 May 2014 17:44:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 May 2014 17:44:01 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4JHhufh032663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 May 2014 13:43:56 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4JHhsgX027671; Mon, 19 May 2014 13:43:54 -0400 Message-ID: <537A42D9.6060006@redhat.com> Date: Mon, 19 May 2014 17:44:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Metzger, Markus T" , Eli Zaretskii CC: "jan.kratochvil@redhat.com" , "gdb-patches@sourceware.org" Subject: Re: [rfc] btrace: control memory access during replay References: <1396601781-25010-1-git-send-email-markus.t.metzger@intel.com> <8361mpa1z9.fsf@gnu.org> <8338hta0hm.fsf@gnu.org> <53738D3E.60606@redhat.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00361.txt.bz2 On 05/19/2014 08:51 AM, Metzger, Markus T wrote: >> -----Original Message----- >> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- >> owner@sourceware.org] On Behalf Of Pedro Alves >> Sent: Wednesday, May 14, 2014 5:35 PM > > >> On 04/04/2014 10:48 AM, Eli Zaretskii wrote: > >>>>> Other than that, the documentation parts are approved. However, I >>>>> wonder whether "allow-memory-access" is a good name for a setting >>>>> which actually allows access to writable portion of the memory. IOW, >>>>> even when the value is OFF, we do allow access to memory, just not the >>>>> writable portion of it. >>>> >>>> Agreed; allow-access-to-writable-memory-while-replaying is a bit long, >> though. >>> >>> How about access-writable-memory? >> >> Sounds fine to me. >> >> What's the likelihood of another variant appearing? That is, >> I'm mildly wondering if it should be an enum from the get go: >> >> set record btrace replay-memory-access read-only|read-write|...|... > > I don't see another variant right now but I also don't see why it > shouldn't be an enum. The kind of variant I was considering was disabling the fallback of reading read only regions as tagged in the binary from live/core memory. But maybe btrace gets completely useless that way. If we can't think of another useful variant, then I'm fine with a boolean, if it sounds more natural. Your choice. >> I also got a little confused with: >> >> "The accessed memory corresponds to the end of the recorded >> execution trace." >> >> Maybe we should say "live program" instead ? > > Would "live program" still be OK for core files? Hmm. I didn't think btrace could work with core files, unlike record full? Are you adding support for dumping/restoring the btrace like "record save" does? >> I actually didn't see anything in the patch that actually makes the >> setting work. > > The patch is using an existing variable to guard writable memory > access. We already allow write-access for breakpoints during > replay. This patch is now adding a CLI for the guard variable. Ah. Thanks. >> Also, please install a show hook in the command, so that i18n >> can work. > > I'm using the default set/show functions with _("") descriptions > for both set and show. Isn't that enough for i18n? Nope. See deprecated_show_value_hack: /* Print doc minus "show" at start. */ print_doc_line (gdb_stdout, c->doc + 5); That can only work in English. > > In case it isn't, would I need a set function, as well? Nope, just the show function is enough. -- Pedro Alves