RE: [PATCH v6 10/10] btrace: Extend ptwrite event decoding.

["Willgerodt, Felix" <felix.willgerodt@intel.com>]

> -----Original Message-----
> From: Eli Zaretskii <eliz@gnu.org>
> Sent: Freitag, 16. September 2022 17:30
> To: Willgerodt, Felix <felix.willgerodt@intel.com>
> Cc: gdb-patches@sourceware.org; Metzger, Markus T
> <markus.t.metzger@intel.com>
> Subject: Re: [PATCH v6 10/10] btrace: Extend ptwrite event decoding.
> 
> > From: "Willgerodt, Felix" <felix.willgerodt@intel.com>
> > CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
> "Metzger,
> >  Markus T" <markus.t.metzger@intel.com>
> > Date: Fri, 16 Sep 2022 14:34:39 +0000
> >
> > > > > Can we rephrase the "and in Python" part to be less confusing and
> > > > > ambiguous?  (Also, there's an extraneous blank character there.)
> > > >
> > > > The NEWS file very often says "in Python".
> > > > But it is a fair point. How about "and in the Python API?"
> > >
> > > I think it is better to use the same wording as you did in the manual.
> >
> > Which is? I can't find anything similar.
> 
>  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
>  @code{RecordAuxiliary} object.

Thanks! I will change it in the next version to:

" GDB now supports printing of ptwrite payloads from the Intel Processor
  Trace during 'record instruction-history', 'record function-call-history'
  and all stepping commands.  The payload is also accessible in Python as a
  RecordAuxiliary object."

> > > > > 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.
> > > >
> > > > That is true. Yet most of the documentation is in python.texi for that
> > > reason.
> > > > Do you think that is not enough?
> > >
> > > I was talking about stuff outside of python.texi.
> >
> > I listed all the stuff outside of python.texi in my previous answer and
> mentioned why
> > I don't see any place where your suggestion would make sense.
> 
> Here:
> 
>   --- a/gdb/doc/gdb.texinfo
>   +++ b/gdb/doc/gdb.texinfo
>   @@ -8017,8 +8017,9 @@ that function, the source lines for this instruction
> sequence (if the
>    @code{/l} modifier is specified), and the instructions numbers that form
>    the sequence (if the @code{/i} modifier is specified).  The function names
>    are indented to reflect the call stack depth if the @code{/c} modifier is
>   -specified.  The @code{/l}, @code{/i}, and @code{/c} modifiers can be
> given
>   -together.
>   +specified.  Printing auxiliary information is enabled by default and can be
>   +omitted with the @code{/a} modifier.  The @code{/l}, @code{/i},
> @code{/a},
>   +and @code{/c} modifiers can be given together.
> 
> Here:
> 
>   --- a/gdb/doc/gdb.texinfo
>   +++ b/gdb/doc/gdb.texinfo
>   @@ -7545,6 +7545,10 @@ Moxie, PowerPC, PowerPC64, S/390, and x86
> (i386/amd64) running
>    GNU/Linux.  Process record and replay can be used both when native
>    debugging, and when remote debugging via @code{gdbserver}.
> 
>   +When recording an inferior, @value{GDBN} may print additional auxiliary
>   +information during stepping commands and commands displaying the
> execution
>   +history.
> 
> And here:
> 
>   --- a/gdb/doc/gdb.texinfo
>   +++ b/gdb/doc/gdb.texinfo
>   @@ -7545,6 +7545,10 @@ Moxie, PowerPC, PowerPC64, S/390, and x86
> (i386/amd64) running
>    GNU/Linux.  Process record and replay can be used both when native
>    debugging, and when remote debugging via @code{gdbserver}.
> 
>   +When recording an inferior, @value{GDBN} may print additional auxiliary
>   +information during stepping commands and commands displaying the
> execution
>   +history.

All of the three are about auxiliary information. As stated previously, that is a
generic infrastructure that will be available independent of Python.
Ptwrite might be the only user right now, but afaik there has
already been discussion about using that infrastructure for some other
feature on the mailing list. Therefore, I still wouldn't add anything to any of
these three.

Regards,
Felix
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928