From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21171 invoked by alias); 26 Feb 2013 09:24:45 -0000 Received: (qmail 21159 invoked by uid 22791); 26 Feb 2013 09:24:43 -0000 X-SWARE-Spam-Status: No, hits=-8.0 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 mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Feb 2013 09:24:37 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 26 Feb 2013 01:23:11 -0800 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 26 Feb 2013 01:24:34 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.108]) by IRSMSX101.ger.corp.intel.com ([169.254.1.96]) with mapi id 14.01.0355.002; Tue, 26 Feb 2013 09:24:32 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: "jan.kratochvil@redhat.com" , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: RE: [rfc] remote, btrace: add branch tracing protocol to Qbtrace packet Date: Tue, 26 Feb 2013 09:24:00 -0000 Message-ID: References: <1361546562-26827-1-git-send-email-markus.t.metzger@intel.com> <512BCA6D.6050909@redhat.com> In-Reply-To: <512BCA6D.6050909@redhat.com> 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/msg00644.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Monday, February 25, 2013 9:33 PM Thanks for your feedback. > > The patch works but I'm not sure whether it is in the spirit of > > the remote serial protocol. >=20 > I'm not sure I have a definite answer. I'll just shoot some > answers/questions, and let's see if we can converse on something. >=20 > Hmm: >=20 > add_packet_config_cmd (&remote_protocol_packets[PACKET_Qbtrace], > - "Qbtrace", "enable-btrace", 0); > + "Qbtrace:bts", "enable-btrace", 0); >=20 > How would you change this when another method in addition to bts > is added? I would add another line, e.g. add_packet_config_cmd (&remote_protocol_packets[PACKET_Qbtrace], "Qbtrace:lbr", "enable-btrace-lbr", 0); > 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 I would create the respective sub-commands dynamically after querying the target. Unfortunately, we cannot remove the commands again on disconnect. As default, GDB will pick one of the supported methods, say, the first in t= he qSupported response. If some GDBserver only supports the foo branch trace recording method and neither bts nor lbr, GDB will pick foo as default and only allow foo to be = configured as recording method. Any GDBserver that supports Qbtrace will need to support Qbtrace:off. If necessary, I can add this to the qSupported packets or we could define "off" as the empty recording method. > > @item Qbtrace > > -The remote stub understands the @samp{Qbtrace} packet. > > +The remote stub understands the @samp{Qbtrace} packet. The branch > > +trace recording method will be specified after the packet name > > +separated by a single colon (@code{:}). There will be one entry for > > +each supported branch trace recording method. >=20 > How are the multiple supported methods separated? There will be separate entries for each supported method in the qSupported response, i.e. ...:Qbtrace:bts+:Qbtrace:lbr+:... > Hmm, I think the user reading this is left wondering what > exactly are the supported methods. >=20 > qSupported already has a way of passing arguments: >=20 > @table @samp > @item @var{name}=3D@var{value} > The remote protocol feature @var{name} is supported, and associated > with the specified @var{value}. The format of @var{value} depends > on the feature, but it must not include a semicolon. > @item @var{name}+ >=20 > So, that'd be, e.g.: >=20 > Qbtrace=3Dbts,foo,bar That would be OK, as well. How would I handle this on GDB side? When GDB wants to enable branch tracing with method foo, what would it send? "Qbtrace=3Dfoo"? > An existing feature that supports multiple values is: >=20 > @item xmlRegisters > This feature indicates that @value{GDBN} supports the XML target > description. If the stub sees @samp{xmlRegisters=3D} with target > specific strings separated by a comma, it will report register > description. Looks like xmlRegisters=3D... is sent by GDB. I would need this to be sent by GDBserver and parsed by GDB. I've also only seen this as parameter to qSupported. Is this a packet on its own, as well? [...] What would be the minimal change required to fix the protocol? Thanks, 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