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 908BA3858015 for ; Thu, 14 Oct 2021 07:12:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 908BA3858015 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36648) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mauvB-0002Iv-0L; Thu, 14 Oct 2021 03:12:57 -0400 Received: from [87.69.77.57] (port=1547 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 1mauv5-00030u-M1; Thu, 14 Oct 2021 03:12:56 -0400 Date: Thu, 14 Oct 2021 10:12:45 +0300 Message-Id: <835yu0m64y.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: (message from Andrew Burgess on Wed, 13 Oct 2021 22:59:10 +0100) Subject: Re: [PATCH 5/5] gdb/python: implement the print_insn extension language hook References: X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 14 Oct 2021 07:12:58 -0000 > From: Andrew Burgess > Date: Wed, 13 Oct 2021 22:59:10 +0100 > > diff --git a/gdb/NEWS b/gdb/NEWS > index d001a03145d..fd1952a2f59 100644 > --- a/gdb/NEWS > +++ b/gdb/NEWS > @@ -32,6 +32,12 @@ maint show internal-warning backtrace > internal-error, or an internal-warning. This is on by default for > internal-error and off by default for internal-warning. > > +set style disassembly on|off > +show style disassembly > + If GDB is compiled with Python support, and the Python pygments > + module is available, then, when this setting is on, disassembler > + output will have styling applied. If this requires Python with a module that is not available by default, I think a general style name like "disassembly" would be misleading. I suggest "pygment-disassembly" instead. > +@item set style disassembly @samp{on|off} > +Enable or disable disassembly styling. This affects whether > +disassembly output, such as the output of the @code{disassemble} > +command, is styled. The default is @samp{on}. Note that disassembly > +styling only works if styling in general is enabled, and if a source > +highlighting library is available to @value{GDBN}. > + > +To highlight disassembly output @value{GDBN} must be compiled with > +Python support, and the Python Pygments package must be available, So what does the default ON setting mean if pygments module is not available, or if GDB was not compiled with Python support? > +@node Disassembly In Python > +@cindex Python Instruction Disassembly Index entries should begin with a lower-case letter, so that sorting of the entries in the produced manual would not depend on the locale. > +@defivar DisassembleInfo can_emit_style_escapes > +This is @code{True} if the output stream that the disassembler is > +currently printing too can support escape sequences use for colors, ^^^ Should be "to". > +otherwise this attribute is @code{False}. Not sure why you are talking about escape sequences: we support styling with colors also on terminals without escape sequences. Does this mean this feature _must_ have actual escape sequence support? > +@defmethod DisassembleInfo memory_error (offset) > +This method marks the @code{DisassembleInfo} as having experienced a > +@code{gdb.MemoryError} when trying to access memory of @var{offset} > +bytes from @code{DisassembleInfo.address}. Should this text have a cross-reference to where MemoryError is described? > +The optional @var{architecture} is either a string, or the value > +@code{None}. If it is a string, then it should be the name of an > +architecture known to @value{GDBN}, as returned either from > +@code{gdb.Architecture.name()} > +(@pxref{gdbpy_architecture_name,,gdb.Architecture.name}), or from > +@code{gdb.architecture_names()} > +(@pxref{gdb_architecture_names,,gdb.architecture_names}). Please remove the parentheses from the references to these methods. > +@defun format_address (architecture, address) > +Returns @var{address} formatted as a string, in a style suitable for > +including in the disassembly output of an instruction, for example a > +formatted address might look like: > + > +@smallexample > +0x00001042 > +@end smallexample > + > +@var{architecture} is a @code{gdb.Architecture} (@pxref{Architectures > +In Python}), which is required to format the addresses correctly. > +This can be obtained from @code{DisassembleInfo.architecture}. This last paragraph should have @noindent before it, since it's a continuation the description of format_address. > +After calling this function the result in @var{info} @emph{might} have > +been updated to include syntax highlighting escape sequences. If > +syntax highlighting is disabled in @value{GDBN}, or the output stream > +doesn't support syntax highlighting, then this function will leave > +@var{info} unchanged. I suggest a cross-reference to commands that enable syntax highlighting where you mention it. > +This function should return a Python object that supports the buffer > +protocol, i.e. a string, an array, or the object returned from Please add @: after i.e., to prevent TeX from typesetting that as an end of a sentence. Thanks.