From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30727 invoked by alias); 28 Feb 2013 08:45:52 -0000 Received: (qmail 30718 invoked by uid 22791); 28 Feb 2013 08:45:51 -0000 X-SWARE-Spam-Status: No, hits=-8.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Feb 2013 08:45:45 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 28 Feb 2013 00:45:44 -0800 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2013 00:45:41 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.108]) by IRSMSX103.ger.corp.intel.com ([169.254.3.15]) with mapi id 14.01.0355.002; Thu, 28 Feb 2013 08:45:23 +0000 From: "Metzger, Markus T" To: Jan Kratochvil , Pedro Alves CC: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: RE: [rfc] remote, btrace: add branch tracing protocol to Qbtrace packet Date: Thu, 28 Feb 2013 09:19:00 -0000 Message-ID: References: <1361546562-26827-1-git-send-email-markus.t.metzger@intel.com> <512BCA6D.6050909@redhat.com> <20130227164738.GA29902@host2.jankratochvil.net> In-Reply-To: <20130227164738.GA29902@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/msg00728.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Wednesday, February 27, 2013 5:48 PM > > 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 >=20 > From the user interface point of view I expected rather: > record full > record btrace > record lbr >=20 > It is already one level of "configuration", two levels of configuration m= ake > it a bit too complicated for the user IMO. Sure the code inside GDB woul= d be > shared between "record-btrace" and "record-lbr" targets but that is hidden > from the user. That should be possible, as well. > > I would create the respective sub-commands dynamically after querying t= he > > target. Unfortunately, we cannot remove the commands again on disconne= ct. >=20 > I do not think there should be dynamically created commands, it is not > established in GDB. I just thought it's more convenient for the user to only be offered commands if the feature is available. I'm OK to add those commands unconditionally. Btw, I think target sub-commands are created dynamically when you call add_= target. > > As default, GDB will pick one of the supported methods, say, the first = in the > > qSupported response. >=20 > Do you expect more "btrace" variants than "bts" and "lbr"? I would expect other processors to offer similar features. > If "lbr" exists it should be enabled by default without asking the user. We could do that until the user requests BTS tracing or full tracing. This = would mean that there would be a record target pushed implicitly. With the current logic, this would prevent displaced stepping and would require an explicit record stop before another record target can be pushed. I think we should discuss the details once we start sending patches to enab= le LBR tracing. > For "bts" one has to type "record btrace" as it is a noticeable slowdown. Agreed. > > There will be separate entries for each supported method in the qSuppor= ted > > response, i.e. > > > > ...:Qbtrace:bts+:Qbtrace:lbr+:... >=20 > colons vs. semicolons mistaken: >=20 > ...;Qbtrace:bts+;Qbtrace:lbr+;... >=20 >=20 > No preference for the qSupported details, I am OK with your proposal myse= lf, > "qXfer" gdbserver->gdb feature is designed that way already. Pedro objected and rather wanted a comma-separated list, i.e. ....;Qbtrace=3Dbts,lbr;... I'm fine either way. For the way I proposed and what seems to be your prefe= rence, as well, I already found code in GDB to handle it. For Pedro's preferred wa= y, I have not found anything that I could reuse. I would like to get the minimal changes in with the btrace series so we don= 't need to rework the protocol later on and are forced to maintain backwards compat= ibility. I do not intend to implement full support for different branch trace record= ing methods right now, since we currently only have one. We will add that suppo= rt when there's a need. Pedro did not respond to my reply. I don't know how to proceed, here. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052