From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12727 invoked by alias); 14 May 2014 15:35:34 -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 12714 invoked by uid 89); 14 May 2014 15:35:34 -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; Wed, 14 May 2014 15:35:33 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4EFZTRb015772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 May 2014 11:35:29 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4EFZQ3u025832; Wed, 14 May 2014 11:35:27 -0400 Message-ID: <53738D3E.60606@redhat.com> Date: Wed, 14 May 2014 15:35: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: Eli Zaretskii , "Metzger, Markus T" CC: palves@redhat.com, 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> In-Reply-To: <8338hta0hm.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00210.txt.bz2 On 04/04/2014 10:48 AM, Eli Zaretskii wrote: >> From: "Metzger, Markus T" >> CC: "palves@redhat.com" , "jan.kratochvil@redhat.com" >> , "gdb-patches@sourceware.org" >> >> Date: Fri, 4 Apr 2014 09:42:46 +0000 >> >>> 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 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 ? Also, I think it'd be good to add an into to the manual explaining the use case. Something like: The btrace record target does not trace data. As a convenience, when replaying, GDB reads read-only memory off the live program directly, assuming that the addresses of the read-only areas don't change. This for example makes it possible to disassemble code while replaying, but not to print variables. In some cases, being able to inspect variables might be useful. You can use the following command for that: and then followed by the docu for the command like you had: +@kindex set record btrace +@item set record btrace allow-memory-access +Control the behavior of the @code{btrace} recording method when +accessing memory during replay. If ON, @value{GDBN} will allow +arbitrary memory accesses. The accessed memory corresponds to the end +of the recorded execution trace. It does not necessarily correspond +to the current replay position. If OFF (the default), @value{GDBN} +will only allow accesses to read-only memory. ... I actually didn't see anything in the patch that actually makes the setting work. Also, please install a show hook in the command, so that i18n can work. Thanks, -- Pedro Alves