From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28799 invoked by alias); 27 Nov 2012 15:36:26 -0000 Received: (qmail 28646 invoked by uid 22791); 27 Nov 2012 15:36:24 -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 15:36:12 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qARFa9xU010574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Nov 2012 10:36:09 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qARFa4VA027048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Nov 2012 10:36:07 -0500 Date: Tue, 27 Nov 2012 15:36: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: <20121127153603.GA1899@host2.jankratochvil.net> References: <1354013351-14791-1-git-send-email-markus.t.metzger@intel.com> <20121127131055.GB22431@host2.jankratochvil.net> <20121127143235.GA31270@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121127143235.GA31270@host2.jankratochvil.net> 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/msg00745.txt.bz2 On Tue, 27 Nov 2012 15:32:35 +0100, Jan Kratochvil wrote: > 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. When thinking about it you can "easily" create backtrace at any point in time backwards as long as you check for call and ret instructions at each recorded PC. Then you would create virtual btrace frames similarly like inline-frame.c and dwarf2-frame-tailcall.c do. Then the finish/reverse-finish/next/reverse-next commands will work automatically from those virtual frames. One could even give proper frame addresses (SP) to the frames thanks to CFI (.eh_frame) valid at each instruction (as long as gcc -fasynchronous-unwind-tables is used). This all could be acceptably fast with no additional overhead during recording. Regards, Jan