From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4953 invoked by alias); 18 Dec 2012 09:20:17 -0000 Received: (qmail 4942 invoked by uid 22791); 18 Dec 2012 09:20:17 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Dec 2012 09:20:01 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBI9JwfV002442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2012 04:19:58 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBI9JrhG015863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Dec 2012 04:19:56 -0500 Date: Tue, 18 Dec 2012 09:20:00 -0000 From: Jan Kratochvil To: markus.t.metzger@intel.com 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 Message-ID: <20121218091953.GF8054@host2.jankratochvil.net> References: <1355760101-26237-1-git-send-email-markus.t.metzger@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355760101-26237-1-git-send-email-markus.t.metzger@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00627.txt.bz2 Hi Markus, already posted about it before: http://sourceware.org/ml/gdb-patches/2012-11/msg00724.html Currently there are two separate history APIs - the "record" one implemented as new target_ops implementing reverse execution via to_resume/to_wait hooks. And now the new API with specific new *btrace* target_ops methods. Without implementing the virtual btrace frames discussed in the thread above one still could implement "reverse-stepi" (and therefore also "reverse-step") on top of btrace by chopping the btrace ranges by lengths of each instruction. 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. record.c has similar "record_list" history, it could be abstracted for both backends via target_ops. 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. Thanks, Jan