From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6501 invoked by alias); 20 May 2014 07:01:22 -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 6490 invoked by uid 89); 20 May 2014 07:01:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 May 2014 07:01:20 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 19 May 2014 23:56:12 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 20 May 2014 00:00:32 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.98]) by IRSMSX101.ger.corp.intel.com ([169.254.1.249]) with mapi id 14.03.0123.003; Tue, 20 May 2014 08:00:31 +0100 From: "Metzger, Markus T" To: Pedro Alves , Eli Zaretskii CC: "jan.kratochvil@redhat.com" , "gdb-patches@sourceware.org" Subject: RE: [rfc] btrace: control memory access during replay Date: Tue, 20 May 2014 07:01:00 -0000 Message-ID: References: <1396601781-25010-1-git-send-email-markus.t.metzger@intel.com> <8361mpa1z9.fsf@gnu.org> <8338hta0hm.fsf@gnu.org> <53738D3E.60606@redhat.com> <537A42D9.6060006@redhat.com> In-Reply-To: <537A42D9.6060006@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00403.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Monday, May 19, 2014 7:44 PM > To: Metzger, Markus T; Eli Zaretskii > >> 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. >=20 > 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. We must be able to read code sections. Without that, btrace will not work. One more option that I can think of is reading from object files. I'll use an enum for the sake of flexibility. > 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? At the moment it can't. I plan to add core file support, though. Regards, Markus. > >> 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. IO= W, > >>>>> 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 lon= g, > >> 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. >=20 > 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. >=20 > >> 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? >=20 > 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? >=20 > >> 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. >=20 > Ah. Thanks. >=20 > >> 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? >=20 > Nope. See deprecated_show_value_hack: >=20 > /* Print doc minus "show" at start. */ > print_doc_line (gdb_stdout, c->doc + 5); >=20 > That can only work in English. >=20 > > > > In case it isn't, would I need a set function, as well? >=20 > Nope, just the show function is enough. >=20 > -- > Pedro Alves Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052