From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126369 invoked by alias); 30 Jun 2015 14:54:41 -0000 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 Received: (qmail 126340 invoked by uid 89); 30 Jun 2015 14:54:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Jun 2015 14:54:36 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 30 Jun 2015 07:54:34 -0700 X-ExtLoop1: 1 Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga002.fm.intel.com with ESMTP; 30 Jun 2015 07:54:32 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 30 Jun 2015 15:54:31 +0100 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.171]) by irsmsx112.ger.corp.intel.com ([169.254.1.163]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 15:54:31 +0100 From: "Metzger, Markus T" To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH 2/5] btrace: support Intel(R) Processor Trace Date: Tue, 30 Jun 2015 14:54:00 -0000 Message-ID: References: <1435047418-21611-1-git-send-email-markus.t.metzger@intel.com> <1435047418-21611-3-git-send-email-markus.t.metzger@intel.com> <55929205.6080907@redhat.com> In-Reply-To: <55929205.6080907@redhat.com> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00638.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Tuesday, June 30, 2015 2:57 PM > To: Metzger, Markus T > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH 2/5] btrace: support Intel(R) Processor Trace >=20 > On 06/23/2015 09:16 AM, Markus Metzger wrote: > > Adds a new command "record btrace pt" to configure the kernel to use > > Intel(R) Processor Trace instead of Branch Trace Strore. >=20 > This looks very good to me. A few minor details to sort out, > and this is good to go. Thanks. > > + decoder =3D pt_insn_alloc_decoder (&config); > > + if (decoder =3D=3D NULL) > > + error (_("Failed to allocate the Intel(R) Processor Trace decoder.= ")); > > + > > + TRY > > + { > > + struct pt_image *image; > > + > > + image =3D pt_insn_get_image(decoder); > > + if (image =3D=3D NULL) > > + error (_("Failed to configure the Intel(R) Processor Trace decoder.")= ); > > + > > + errcode =3D pt_image_set_callback(image, > btrace_pt_readmem_callback, NULL); > > + if (errcode < 0) > > + error (_("Failed to configure the Intel(R) Processor Trace decoder: " > > + "%s."), pt_errstr (pt_errcode (errcode))); > > + > > + ftrace_add_pt (decoder, &btinfo->begin, &btinfo->end, &level, > > + &btinfo->ngaps); > > + } > > + CATCH (error, RETURN_MASK_ALL) > > + { > > + /* Indicate a gap in the trace if we quit trace processing. Err= ors were > > + already logged before. */ >=20 > What does this "already logged before" mean? AFAICS, the errors thrown > in the TRY branch are just swallowed here. Did you mean to rethrow them? > Otherwise I'm not seeing the point in throwing them in the first place. This means that decode errors are already represented as gaps in the trace. When the trace is printed, the error at a trace gap is printed. This code is now handling a user interrupt, which is also represented as a gap at the very end of the trace. This reference to decode errors is maybe more confusing than helpful. I'll remove it. > > internal_error (__FILE__, __LINE__, _("Unkown branch trace format.")= ); > > @@ -1056,7 +1312,7 @@ check_xml_btrace_version (struct > gdb_xml_parser *parser, > > { > > const char *version =3D xml_find_attribute (attributes, "version")->= value; > > > > - if (strcmp (version, "1.0") !=3D 0) > > + if (strcmp (version, "1.0") !=3D 0 && strcmp (version, "2.0") !=3D 0) >=20 > What fails if you send the new xml to an old/unpatched gdb, while keeping > the > version at 1.0? Is the new file really incompatible, or are you just > adding new elements/attributes? There's usually no need to bump the > version in the latter case. Old gdb will just ignore the > elements/attributes it doesn't recognize, and thus not support the featur= e. I'm just adding new elements and attributes. I thought I'd bump the version since there are new features. Should I leave it at version 1.0? 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