From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14515 invoked by alias); 18 Dec 2012 10:14:11 -0000 Received: (qmail 14476 invoked by uid 22791); 18 Dec 2012 10:14:08 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Dec 2012 10:13:38 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 18 Dec 2012 02:12:44 -0800 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 18 Dec 2012 02:13:35 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.95]) by IRSMSX104.ger.corp.intel.com ([169.254.5.151]) with mapi id 14.01.0355.002; Tue, 18 Dec 2012 10:12:50 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "palves@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: RE: [patch v6 00/12] branch tracing support for Atom Date: Tue, 18 Dec 2012 10:14:00 -0000 Message-ID: References: <1355760101-26237-1-git-send-email-markus.t.metzger@intel.com> <20121218091953.GF8054@host2.jankratochvil.net> In-Reply-To: <20121218091953.GF8054@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2012-12/txt/msg00628.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Tuesday, December 18, 2012 10:20 AM > To: Metzger, Markus T > Cc: palves@redhat.com; tromey@redhat.com; kettenis@gnu.org; gdb-patches@s= ourceware.org; markus.t.metzger@gmail.com > Subject: Re: [patch v6 00/12] branch tracing support for Atom >=20 > Hi Markus, >=20 > already posted about it before: > http://sourceware.org/ml/gdb-patches/2012-11/msg00724.html >=20 > Currently there are two separate history APIs - the "record" one implemen= ted > as new target_ops implementing reverse execution via to_resume/to_wait ho= oks. > And now the new API with specific new *btrace* target_ops methods. >=20 > Without implementing the virtual btrace frames discussed in the thread ab= ove > one still could implement "reverse-stepi" (and therefore also "reverse-st= ep") > on top of btrace by chopping the btrace ranges by lengths of each instruc= tion. >=20 > There is even existing "record goto" command which is similar to the new > command "btrace +[]/-[]" interface which partially duplicates > stepi/reverse-stepi. While the diassembling and "list" feature would be > useful also with the record target. >=20 > record.c has similar "record_list" history, it could be abstracted for bo= th > backends via target_ops. >=20 > OTOH I should have reacted much earlier and be more explicit in the mail = above > so not going to block it but neither approve it. IMO the two interfaces > should be unified. I like the idea of adding BTS as a configuration option to "record" to prov= ide a control-flow only trace for the reverse- commands. This will be quite= limited since the only thing you can really do is iterate over disassembly= and source lines - plus some fake back trace. On the other hand, recording= is faster and control-flow-only trace may suffice in some cases. We should not remove the existing btrace commands, though. They provide a c= ompact means of viewing the control-flow trace. With a single "btrace list"= command, you get a compact overview of the control flow that led to the cu= rrent location. With a single "btrace 1-8" command, you get the full disass= embly of the last 8 blocks in control-flow order. Using the remote- command= s, you would need a sequence of reverse-stepi or reverse-step commands. And= even then, the output would be clobbered with intermixed prompts and would= be in reverse control-flow order, unless you navigated back and forth agai= n. Depending on your use case, either the btrace or the remote- commands are m= ore effective. As far as I understand, the btrace commands could also be implemented for "= record" to provide a more compact view of the recorded control-flow. They c= ould thus also help improve the "record" feature. Given the different use cases, it would make sense to establish two sets of= commands for all kinds of control-flow tracing/replay: one for viewing and= one for navigating. In a first step, BTS tracing will only implement the f= ormer and "record" will only implement the latter. In a second step, "recor= d" could implement the viewing commands, and in third step, BTS tracing ca= n implement the navigation commands. Would that be OK with you? Regards, Markus. 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