From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28187 invoked by alias); 18 Dec 2012 13:55:22 -0000 Received: (qmail 28176 invoked by uid 22791); 18 Dec 2012 13:55:21 -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 13:54:50 +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 qBIDsh43020859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2012 08:54:44 -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 qBIDsbuR008228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Dec 2012 08:54:40 -0500 Date: Tue, 18 Dec 2012 13:55:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" 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: <20121218135437.GA16636@host2.jankratochvil.net> References: <1355760101-26237-1-git-send-email-markus.t.metzger@intel.com> <20121218091953.GF8054@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-12/txt/msg00629.txt.bz2 On Tue, 18 Dec 2012 11:12:49 +0100, Metzger, Markus T wrote: > I like the idea of adding BTS as a configuration option to "record" to > provide 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 Yes. But without teaching users new commands, one of the issues of GDB. I find myself to prefer the already used reverse-stepi even with BTS. > - plus some fake back trace. I would exclude that feature from the current discussion as it can be implemented as an add-on patch without changing much other code. > We should not remove the existing btrace commands, though. In general I agree. Just they should be moved under the "record" prefix. Command "btrace" then should be renamed to some "record disassemble". And for example the "btrace" current position should be shared with "reverse-*" current position and the btrace args parser/syntax should be unified with "record goto" syntax. That means only supporting start/begin/end as otherwise btrace syntax is more rich than the record one - but the goal is to make the syntax compatible for users. > Using the remote- commands, 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 again. I agree. Just "reverse-step" is a more general command - even for record - while still usable for the basic use case of BTS. > Depending on your use case, either the btrace or the remote- commands are > more effective. Yes. > 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 > could thus also help improve the "record" feature. Exactly. That both record navigation commands are useful (or at least usable) for BTS and that BTS view commands are definitely useful for record proves to me they should share the same backend/data. > 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 > former and "record" will only implement the latter. In a second step, > "record" could implement the viewing commands, and in third step, BTS > tracing can implement the navigation commands. > > Would that be OK with you? I believe you a heading for an approval of this patchset as is, so that the unification can be implemented in an add-on patch series. I do not think the unification patch series will get checked-in soon enough for gdb-7.6. That means the currently defined commands will need to remain backward comparible indefinitely in the future. So one should make the commands syntax final already (there is deprecate_cmd but it is not good to plan its use). I believe the internal API will change a lot for the unification with record backend/data so it seems to me a large part of the patch will need to get replaced afterwards. But I am OK with that if we at least make the commands unified with record with some hope the backend functionality unification will come later. Thanks, Jan