From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 2A48A396E86E for ; Fri, 16 Sep 2022 12:01:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2A48A396E86E Received: from fencepost.gnu.org ([2001:470:142:3::e]:36378) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZA2R-0004Bs-02; Fri, 16 Sep 2022 08:01:43 -0400 Received: from [87.69.77.57] (port=1129 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZA2Q-0002xH-CK; Fri, 16 Sep 2022 08:01:42 -0400 Date: Fri, 16 Sep 2022 15:01:36 +0300 Message-Id: <831qsb4jfj.fsf@gnu.org> From: Eli Zaretskii To: Felix Willgerodt Cc: gdb-patches@sourceware.org, markus.t.metzger@intel.com In-Reply-To: <20220916113646.49749-11-felix.willgerodt@intel.com> (message from Felix Willgerodt via Gdb-patches on Fri, 16 Sep 2022 13:36:46 +0200) Subject: Re: [PATCH v6 10/10] btrace: Extend ptwrite event decoding. References: <20220916113646.49749-1-felix.willgerodt@intel.com> <20220916113646.49749-11-felix.willgerodt@intel.com> X-Spam-Status: No, score=1.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2022 12:01:50 -0000 > Date: Fri, 16 Sep 2022 13:36:46 +0200 > From: Felix Willgerodt via Gdb-patches > > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -3,6 +3,12 @@ > > *** Changes since GDB 12 > > +* GDB now supports printing of ptwrite payloads from the Intel Processor > + Trace during 'record instruction-history', 'record function-call-history', > + all stepping commands and in Python. Printing is customizable via a Can we rephrase the "and in Python" part to be less confusing and ambiguous? (Also, there's an extraneous blank character there.) > +If an inferior uses the instruction, @value{GDBN} by default inserts the > +raw payload value as auxiliary information into the execution history. > +Auxiliary information is by default printed during > +@code{record instruction-history}, @code{record function-call-history}, > +and all stepping commands and is accessible in Python as a ^ Comma missing there. Btw, it sounds like this functionality is only available if GDB was built with Python? If so, I think other places where you mention this in the manual should indicate that the feature is only available through Python. > +This function will be called with the ptwrite payload and PC as arguments > +during trace decoding. ^^^^^^^ @code{ptwrite}. Also, please decide whether you want to use "ptwrite" in lower-case or PTWRITE in upper-case, and please use the same convention everywhere in the manual. I also think talking about a "payload" obfuscates the description for no good reason. It's just a value of some data type supported by the 'ptwrite' instruction, right? If so, I think "value" is much clearer and less mysterious. > +@findex gdb.ptwrite.register_filter > +@defun register_filter (@var{filter}) > +Used to register the ptwrite filter. The filter can be any callable ^^^^^^^ @code{ptwrite} > +@findex gdb.ptwrite.get_filter > +@defun get_filter () > +Returns the currently active ptwrite filter function. I think our style is to say "Return", not "Returns". Thanks.