From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20629 invoked by alias); 27 Feb 2013 16:48:11 -0000 Received: (qmail 20095 invoked by uid 22791); 27 Feb 2013 16:48:01 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,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; Wed, 27 Feb 2013 16:47:45 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1RGlhg2019118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Feb 2013 11:47:43 -0500 Received: from host2.jankratochvil.net (ovpn-116-19.ams2.redhat.com [10.36.116.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1RGlddi017968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 11:47:41 -0500 Date: Wed, 27 Feb 2013 16:48:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: Pedro Alves , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: Re: [rfc] remote, btrace: add branch tracing protocol to Qbtrace packet Message-ID: <20130227164738.GA29902@host2.jankratochvil.net> References: <1361546562-26827-1-git-send-email-markus.t.metzger@intel.com> <512BCA6D.6050909@redhat.com> 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: 2013-02/txt/msg00689.txt.bz2 On Tue, 26 Feb 2013 10:24:32 +0100, Metzger, Markus T wrote: > > What if a remote stub sends in "Qbtrace:foo", but no mention of > > bts? The remote understands "Qbtrace:off", but this does not > > express that. > > At the moment, GDB and GDBserver equate btrace with btrace-bts. > > Eventually, I want GDB to collect all the supported btrace methods and allow > the user to specify one of the supported methods, i.e. > > set record btrace method bts > set record btrace method lbr >From the user interface point of view I expected rather: record full record btrace record lbr It is already one level of "configuration", two levels of configuration make it a bit too complicated for the user IMO. Sure the code inside GDB would be shared between "record-btrace" and "record-lbr" targets but that is hidden from the user. > I would create the respective sub-commands dynamically after querying the > target. Unfortunately, we cannot remove the commands again on disconnect. I do not think there should be dynamically created commands, it is not established in GDB. > As default, GDB will pick one of the supported methods, say, the first in the > qSupported response. Do you expect more "btrace" variants than "bts" and "lbr"? If "lbr" exists it should be enabled by default without asking the user. For "bts" one has to type "record btrace" as it is a noticeable slowdown. Or do I miss some plans? > There will be separate entries for each supported method in the qSupported > response, i.e. > > ...:Qbtrace:bts+:Qbtrace:lbr+:... colons vs. semicolons mistaken: ...;Qbtrace:bts+;Qbtrace:lbr+;... No preference for the qSupported details, I am OK with your proposal myself, "qXfer" gdbserver->gdb feature is designed that way already. Thanks, Jan