From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8928 invoked by alias); 27 Nov 2012 13:11:10 -0000 Received: (qmail 8870 invoked by uid 22791); 27 Nov 2012 13:11:09 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 27 Nov 2012 13:11:05 +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 qARDB2es020816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 08:11:03 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qARDAvrc024829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 08:11:00 -0500 Date: Tue, 27 Nov 2012 13:11:00 -0000 From: Jan Kratochvil To: markus.t.metzger@intel.com Cc: gdb-patches@sourceware.org, markus.t.metzger@gmail.com, palves@redhat.com, tromey@redhat.com, kettenis@gnu.org Subject: Re: [patch v4 00/13] branch tracing support for Atom Message-ID: <20121127131055.GB22431@host2.jankratochvil.net> References: <1354013351-14791-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: <1354013351-14791-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-11/txt/msg00724.txt.bz2 On Tue, 27 Nov 2012 11:48:58 +0100, markus.t.metzger@intel.com wrote: > - "btrace list" prints the blocks that have been traced; one line per block. [...] > - "btrace" prints the branch trace disassembly I see a partially similar reverse execution feature for GDB I use. There one can easily find the interesting spot using the back-and-forth moving in the history using reverse-next, reverse-step, reverse-finish, but even finding back the spot by regular step/next/finish (only stepping in history). But with reverse execution one (I) commonly use also watchpoints to find the spot, which is apparently not applicable with btrace. Also the natural "backtrace" command would not work with btrace. While the most correct way would be to make all memory as in practice one may want to print variables when stepping in the btrace history so there could be an exception for "print" command to temporarily make memory available with a warning. Just such an idea. Reverse execution does not have such feature of the "listing" of its history. So unifying their interface could provide both "reverse-*" commands functionality with btrace and "listing" of the reverse-execution history. Being used to reverse execution I find more natural to "reverse-step" to look where the inferior was before a moment. But not sure if unifying btrace with reverse execution is a good idea at all having no practical experience with btrace yet. Thanks, Jan