[PATCH 5/5] gdb/python: document GDB/MI commands in Python

Jan Vrany jan.vrany@labware.com
Tue Jan 18 12:34:00 GMT 2022


Hi, 
> 
> > Date: Mon, 17 Jan 2022 12:44:25 +0000
> > From: Jan Vrany via Gdb-patches <gdb-patches@sourceware.org>
> > Cc: Jan Vrany <jan.vrany@labware.com>
> > 
> > --- a/gdb/NEWS
> > +++ b/gdb/NEWS
> > @@ -146,6 +146,8 @@ show debug lin-lwp
> >    ** New function gdb.host_charset(), returns a string, which is the
> >       name of the current host charset.
> >  
> > 
> > 
> > 
> > +  ** New GDB/MI commands can now be written in Python.
> 
> The "new" part here took me by surprise.  Why do we need it?
> 
> Or how about this rewording:
> 
>   ** It is now possible to add GDB/MI commands implemented in Python.
> 
> > +* GDB/MI Commands In Python::   Implementing new @sc{GDB/MI} commands in Python.
>                                                     ^^^^^^^^^^^
> The argument of @sc should be in lower case.
> 
> > +@cindex CLI commands in python
> >  @cindex commands in python
> >  @cindex python commands
> >  You can implement new @value{GDBN} CLI commands in Python.  A CLI
> > @@ -4092,6 +4095,71 @@ registration of the command with @value{GDBN}.  Depending on how the
> >  Python code is read into @value{GDBN}, you may need to import the
> >  @code{gdb} module explicitly.
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > +@node GDB/MI Commands In Python
> > +@subsubsection @sc{GDB/MI} Commands In Python
> > +
> > +@cindex MI commands in python
> > +@cindex commands in python
> > +@cindex python commands
> 
> You've added a second copy of the last two index entries, without any
> qualifier.  This will cause makeinfo to generate index entries
> "commands in python" and "commands is python<2>", without giving the
> reader any clue what is the difference between these two instances.
> 
> It is much better to qualify each instance with some unique
> qualifier.  Here, I'd use ", CLI" and ", GDB/MI" as the qualifiers.

I see. However I'm not sure what do you mean by "qualifiers". 
In new version (which I'll submit  once I get review on
other patches in this series) I changed index entries to 

@node CLI Commands In Python
@subsubsection CLI Commands In Python

@cindex commands in python @subentry CLI
@cindex python commands @subentry CLI

and then 

@node GDB/MI Commands In Python
@subsubsection @sc{gdb/mi} Commands In Python

@cindex commands in python @subentry @sc{gdb/mi}
@cindex python commands @subentry @sc{gdb/mi}

It looks good to me in HTML version. 

Is that what you meant? It seems that this is the first use
of @subentry in @cindex in GDB manual so perhaps you meant
something different? 


> 
> > +You can implement new @sc{GDB/MI} (@pxref{GDB/MI}) commands in Python.
> 
> Same comment as for the NEWS entry.  With a possibly similar solution.

This phrasing with "new" (both here and in NEWS) was taken from entries
for CLI commands. For NEWS, I have changed it as you suggested, it's better.

But for manual it makes less sense to me. Wording "It is now possible to add GDB/MI 
commands implemented in Python." sounds to me as to suggest this is some
new feature. It makes sense for NEWS but perhaps might look bit weird after
5 years (given that this series gets in) when this is no new feature. 

Maybe I'm misunderstanding something...

> 
> > +@var{name} is the name of the command.  It must be a valid @sc{GDB/MI}
> > +command and must start with hyphen (-).
> 
> What does "It must be a valid @sc{GDB/MI} command" mean here?  Did you
> mean to say "It must be a valid @sc{GDB/MI} command name" instead?  If
> so, I suggest
> 
>   It must be a valid name of a @sc{GDB/MI} command, and in particular
>   must start with a hyphen (@samp{-}).
> 
> > +@var{arguments} is a list of strings.  Note, that @code{--thread}
> > +and @code{--frame} arguments are handled by @value{GDBN} itself therefore
> > +they do not show up in @code{arguments}.                       ^
> 
> Comma missing there.
> 
> > +If this method throws an exception, it is turned into a @sc{GDB/MI}
> 
> "it" here is ambiguous: does it mean the exception or does it mean the
> method?  Suggest to be more explicit:
> 
>   If this method throws an exception, the exception is turned into a
>   @sc{GDB/MI} @code{^error} response.
> 
> > +@itemize
> > +@item If the value is Python sequence or iterator, it is converted to
> > +@sc{GDB/MI} @emph{list} with elements converted recursively.
> 
> In an @itemize list, eacg @item should be alone on its line (unlike in
> a @table).
> 
> > +@item If the value is Python dictionary, it is converted to
> > +@sc{GDB/MI} @emph{tuple}.
> 
> I don't think using @emph here is a good idea.  I think @code is
> better.  @mph will look odd in Info.
> 
> 

I changed all the rest as suggested.

Thanks! Jan



More information about the Gdb-patches mailing list