From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13380 invoked by alias); 27 Nov 2012 14:32:53 -0000 Received: (qmail 13370 invoked by uid 22791); 27 Nov 2012 14:32:52 -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 14:32:43 +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 qAREWffo030715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 09:32:41 -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 qAREWaFh016781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 09:32:39 -0500 Date: Tue, 27 Nov 2012 14:32:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" 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: <20121127143235.GA31270@host2.jankratochvil.net> References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <20121127131055.GB22431@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00736.txt.bz2 On Tue, 27 Nov 2012 15:25:39 +0100, Metzger, Markus T wrote: > I would also expect problems with stepping, since we won't be able to fake > a back trace using branch trace data. I don't expect that commands like > reverse-next, next, and finish would work without special cases for btrace. It is true these commands implemented on btrace would need to disassemble x86* instructions (like reverse-execution does for the memory recording purpose), as you state backtrace is not available there which they depend upon. It would be a larger work. > Regarding the btrace list feature, this might be something we may want to > add to reverse execution. It gives an overview over the executed code in > a very compact format. If people find this useful, we could compute > something similar from the reverse execution history. It depends on whether there could be a common internal interface to both. Thanks, Jan