## Appendix D Maintenance Commands ¶

In addition to commands intended for GDB users, GDB includes a number of commands intended for GDB developers, that are not documented elsewhere in this manual. These commands are provided here for reference. (For commands that turn on debugging messages, see Optional Messages about Internal Happenings.)

`maint agent [-at linespec,] expression` ¶
`maint agent-eval [-at linespec,] expression`

  Translate the given expression into remote agent bytecodes. This command is useful for debugging the Agent Expression mechanism (see The GDB Agent Expression Mechanism). The ‘`agent`’ version produces an expression useful for data collection, such as by tracepoints, while ‘`maint agent-eval`’ produces an expression that evaluates directly to a result. For instance, a collection expression for `globa + globb` will include bytecodes to record four bytes of memory at each of the addresses of `globa` and `globb`, while discarding the result of the addition, while an evaluation expression will do the addition and return the sum. If `-at` is given, generate remote agent bytecode for all the addresses to which linespec resolves (see Linespec Locations). If not, generate remote agent bytecode for current frame PC address.

`maint agent-printf format,expr,...` ¶

  Translate the given format string and list of argument expressions into remote agent bytecodes and display them as a disassembled list. This command is useful for debugging the agent version of dynamic printf (see Dynamic Printf).

`maint info breakpoints`

  Using the same format as ‘`info breakpoints`’, display both the breakpoints you’ve set explicitly, and those GDB is using for internal purposes. Internal breakpoints are shown with negative breakpoint numbers. The type column identifies what kind of breakpoint is shown:

  `breakpoint`

    Normal, explicitly set breakpoint.

  `watchpoint`

    Normal, explicitly set watchpoint.

  `longjmp`

    Internal breakpoint, used to handle correctly stepping through `longjmp` calls.

  `longjmp resume`

    Internal breakpoint at the target of a `longjmp`.

  `until`

    Temporary internal breakpoint used by the GDB `until` command.

  `finish`

    Temporary internal breakpoint used by the GDB `finish` command.

  `shlib events`

    Shared library events.

`maint info btrace` ¶

  Pint information about raw branch tracing data.

`maint btrace packet-history` ¶

  Print the raw branch trace packets that are used to compute the execution history for the ‘`record btrace`’ command. Both the information and the format in which it is printed depend on the btrace recording format.

  `bts`

    For the BTS recording format, print a list of blocks of sequential code. For each block, the following information is printed:

    Block number

      Newer blocks have higher numbers. The oldest block has number zero.

    Lowest ‘`PC`’
    Highest ‘`PC`’
  `pt`

    For the Intel Processor Trace recording format, print a list of Intel Processor Trace packets. For each packet, the following information is printed:

    Packet number

      Newer packets have higher numbers. The oldest packet has number zero.

    Trace offset

      The packet’s offset in the trace stream.

    Packet opcode and payload
`maint btrace clear-packet-history` ¶

  Discards the cached packet history printed by the ‘`maint btrace packet-history`’ command. The history will be computed again when needed.

`maint btrace clear` ¶

  Discard the branch trace data. The data will be fetched anew and the branch trace will be recomputed when needed.

  This implicitly truncates the branch trace to a single branch trace buffer. When updating branch trace incrementally, the branch trace available to GDB may be bigger than a single branch trace buffer.

`maint set btrace pt skip-pad` ¶
`maint show btrace pt skip-pad`

  Control whether GDB will skip PAD packets when computing the packet history.

`maint info jit` ¶

  Print information about JIT code objects loaded in the current inferior.

`maint info python-disassemblers` ¶

  This command is defined within the `gdb.disassembler` Python module (see Instruction Disassembly In Python), and will only be present after that module has been imported. To force the module to be imported do the following:

`maint info linux-lwps` ¶

  Print information about LWPs under control of the Linux native target.

      (gdb) python import gdb.disassembler

  This command lists all the architectures for which a disassembler is currently registered, and the name of the disassembler. If a disassembler is registered for all architectures, then this is listed last against the ‘`GLOBAL`’ architecture.

  If one of the disassemblers would be selected for the architecture of the current inferior, then this disassembler will be marked.

  The following example shows a situation in which two disassemblers are registered, initially the ‘`i386`’ disassembler matches the current architecture, then the architecture is changed, now the ‘`GLOBAL`’ disassembler matches.

      (gdb) show architecture
      The target architecture is set to "auto" (currently "i386").
      (gdb) maint info python-disassemblers
      Architecture        Disassember Name
      i386                Disassembler_1	(Matches current architecture)
      GLOBAL              Disassembler_2

      (gdb) set architecture arm
      The target architecture is set to "arm".
      (gdb) maint info python-disassemblers
      quit
      Architecture        Disassember Name
      i386                Disassembler_1
      GLOBAL              Disassembler_2	(Matches current architecture)

`set displaced-stepping` ¶
`show displaced-stepping`

  Control whether or not GDB will do displaced stepping if the target supports it. Displaced stepping is a way to single-step over breakpoints without removing them from the inferior, by executing an out-of-line copy of the instruction that was originally at the breakpoint location. It is also known as out-of-line single-stepping.

  `set displaced-stepping on`

    If the target architecture supports it, GDB will use displaced stepping to step over breakpoints.

  `set displaced-stepping off`

    GDB will not use displaced stepping to step over breakpoints, even if such is supported by the target architecture.

  `set displaced-stepping auto` ¶

    This is the default mode. GDB will use displaced stepping only if non-stop mode is active (see Non-Stop Mode) and the target architecture supports displaced stepping.

`maint check-psymtabs` ¶

  Check the consistency of currently expanded psymtabs versus symtabs. Use this to check, for example, whether a symbol is in one but not the other.

`maint check-symtabs` ¶

  Check the consistency of currently expanded symtabs.

`maint expand-symtabs [regexp]` ¶

  Expand symbol tables. If regexp is specified, only expand symbol tables for file names matching regexp.

`maint set catch-demangler-crashes [on|off]` ¶
`maint show catch-demangler-crashes`

  Control whether GDB should attempt to catch crashes in the symbol name demangler. The default is to attempt to catch crashes. If enabled, the first time a crash is caught, a core file is created, the offending symbol is displayed and the user is presented with the option to terminate the current session.

`maint cplus first_component name` ¶

  Print the first C`++` class/namespace component of name.

`maint cplus namespace` ¶

  Print the list of possible C`++` namespaces.

`maint deprecate command [replacement]` ¶
`maint undeprecate command`

  Deprecate or undeprecate the named command. Deprecated commands cause GDB to issue a warning when you use them. The optional argument replacement says which newer command should be used in favor of the deprecated one; if it is given, GDB will mention the replacement as part of the warning.

`maint dump-me` ¶

  Cause a fatal signal in the debugger and force it to dump its core. This is supported only on systems which support aborting a program with the `SIGQUIT` signal.

`maint internal-error [message-text]` ¶
`maint internal-warning [message-text]`
`maint demangler-warning [message-text]`

  Cause GDB to call the internal function `internal_error`, `internal_warning` or `demangler_warning` and hence behave as though an internal problem has been detected. In addition to reporting the internal problem, these functions give the user the opportunity to either quit GDB or (for `internal_error` and `internal_warning`) create a core file of the current GDB session.

  These commands take an optional parameter message-text that is used as the text of the error or warning message.

  Here’s an example of using `internal-error`:

      (gdb) maint internal-error testing, 1, 2
      .../maint.c:121: internal-error: testing, 1, 2
      A problem internal to GDB has been detected.  Further
      debugging may prove unreliable.
      Quit this debugging session? (y or n) n
      Create a core file? (y or n) n
      (gdb)

`maint set debuginfod download-sections` ¶
`maint set debuginfod download-sections [on|off]`
`maint show debuginfod download-sections`

  Controls whether GDB will attempt to download individual ELF/DWARF sections from `debuginfod`. If disabled, only whole debug info files will be downloaded; this could result in GDB downloading larger amounts of data.

`maint set internal-error action [ask|yes|no]` ¶
`maint show internal-error action`
`maint set internal-warning action [ask|yes|no]`
`maint show internal-warning action`
`maint set demangler-warning action [ask|yes|no]`
`maint show demangler-warning action`

  When GDB reports an internal problem (error or warning) it gives the user the opportunity to both quit GDB and create a core file of the current GDB session. These commands let you override the default behavior for each particular action, described in the table below.

  ‘`quit`’

    You can specify that GDB should always (yes) or never (no) quit. The default is to ask the user what to do.

  ‘`corefile`’

    You can specify that GDB should always (yes) or never (no) create a core file. The default is to ask the user what to do. Note that there is no `corefile` option for `demangler-warning`: demangler warnings always create a core file and this cannot be disabled.

`maint set internal-error backtrace [on|off]` ¶
`maint show internal-error backtrace`
`maint set internal-warning backtrace [on|off]`
`maint show internal-warning backtrace`

  When GDB reports an internal problem (error or warning) it is possible to have a backtrace of GDB printed to the standard error stream. This is ‘`on`’ by default for `internal-error` and ‘`off`’ by default for `internal-warning`.

`maint packet text` ¶

  If GDB is talking to an inferior via the serial protocol, then this command sends the string text to the inferior, and displays the response packet. GDB supplies the initial ‘`$`’ character, the terminating ‘`#`’ character, and the checksum.

  Any non-printable characters in the reply are printed as escaped hex, e.g. ‘`\x00`’, ‘`\x01`’, etc.

`maint print architecture [file]` ¶

  Print the entire architecture configuration. The optional argument file names the file where the output goes.

`maint print c-tdesc [-single-feature] [file]` ¶

  Print the target description (see Target Descriptions) as a C source file. By default, the target description is for the current target, but if the optional argument file is provided, that file is used to produce the description. The file should be an XML document, of the form described in Target Description Format. The created source file is built into GDB when GDB is built again. This command is used by developers after they add or modify XML target descriptions.

  When the optional flag ‘`-single-feature`’ is provided then the target description being processed (either the default, or from file) must only contain a single feature. The source file produced is different in this case.

  The file argument supports escaping and quoting, see Filenames As Command Arguments.

`maint print xml-tdesc [file]` ¶

  Print the target description (see Target Descriptions) as an XML file. By default print the target description for the current target, but if the optional argument file is provided, then that file is read in by GDB and then used to produce the description. The file should be an XML document, of the form described in Target Description Format.

`maint check xml-descriptions dir` ¶

  Check that the target descriptions dynamically created by GDB equal the descriptions created from XML files found in dir.

`maint check libthread-db` ¶

  Run integrity checks on the current inferior’s thread debugging library. This exercises all `libthread_db` functionality used by GDB on GNU/Linux systems, and by extension also exercises the `proc_service` functions provided by GDB that `libthread_db` uses. Note that parts of the test may be skipped on some platforms when debugging core files.

`maint print core-file-backed-mappings` ¶

  Print the file-backed mappings which were loaded from a core file note. This output represents state internal to GDB and should be similar to the mappings displayed by the `info proc mappings` command.

`maint print dummy-frames` ¶

  Prints the contents of GDB’s internal dummy-frame stack.

      (gdb) b add
      ...
      (gdb) print add(2,3)
      Breakpoint 2, add (a=2, b=3) at ...
      58	  return (a + b);
      The program being debugged stopped while in a function called from GDB.
      ...
      (gdb) maint print dummy-frames
      0xa8206d8: id={stack=0xbfffe734,code=0xbfffe73f,!special}, ptid=process 9353
      (gdb)

  Takes an optional file parameter.

`maint print frame-id` ¶
`maint print frame-id level`

  Print GDB’s internal frame-id for the frame at relative level, or for the currently selected frame when level is not given.

  If used, level should be an integer, as displayed in the `backtrace` output.

      (gdb) maint print frame-id
      frame-id for frame #0: {stack=0x7fffffffac70,code=0x0000000000401106,!special}
      (gdb) maint print frame-id 2
      frame-id for frame #2: {stack=0x7fffffffac90,code=0x000000000040111c,!special}

`maint info inline-frames` ¶
`maint info inline-frames address`

  Print information about inlined frames which start at the current address, or address if specified.

  In order to allow the user to correctly step into inlined functions, GDB needs to identify which inlined functions start at a particular address, and GDB also needs to track which of these functions was last displayed to the user as the current frame.

  Imagine a situation where function `main` calls `foo`, which then calls `bar`, something like this:

      int
      main ()
      {
        /* Some interesting code here...  */

        foo ();

        /* More interesting code here... */
      }

      void
      foo ()
      {
        bar ();
      }

      void
      bar ()
      {
        /* Some interesting code here...  */
      }

  As both `foo` and `bar` are inlined within `main` then there could be one address within `main` which is also the start of `foo` and also the start of `bar`. When the user stops at this address they will initially be told the inferior is in `main`, if the user does a `step` then GDB doesn’t actually step the inferior, instead the user is told the inferior entered `foo`. After the next `step` the user is told the inferior entered `bar`. The `maint info inline-frames` command can be used to view this internal GDB state, like this:

      (gdb) step
      24	  foo ();
      (gdb) maintenance info inline-frames
      Cached inline state information for thread 1.
      program counter = 0x401137
      skipped frames = 2
        bar
        foo
      > main

  Here the user is stopped in `main` at the call to `foo`. The inline-frames information shows that at this address GDB has found the start of inlined functions `bar` and `foo`, but currently GDB has skipped 2 frames and considers `main` to be the current frame, this is indicated with the ‘`>`’.

  If the user performs a `step` to enter `foo` then the situation is updated:

      (gdb) step
      foo () at inline.c:14
      14	  bar ();
      (gdb) maintenance info inline-frames
      Cached inline state information for thread 1.
      program counter = 0x401137
      skipped frames = 1
        bar
      > foo
        main

  Notice that the program counter value `0x401137` hasn’t change, but now GDB considers `foo` to be the current frame, and it is marked as such with the ‘`>`’.

  Finally, the user performs another `step` to enter `bar`:

      (gdb) step
      bar () at inline.c:6
      6	  ++global_counter;
      (gdb) maintenance info inline-frames
      Cached inline state information for thread 1.
      program counter = 0x401137
      skipped frames = 0
      > bar
        foo
        main

`maint info blocks` ¶
`maint info blocks address`

  Print information about all blocks at address, or at the current `$pc` if address is not given.

  For information about what blocks are in GDB see Accessing blocks from Python.

  Blocks are listed starting from the global block, then the static block, and then proceeding through progressively narrower scopes.

  Here is an example of the command’s output:

      (gdb) maintenance info blocks
      Blocks at 0x401137:
        from objfile: [(objfile *) 0x50507d0] /tmp/inline_func_demo

      [(block *) 0x504da90] 0x401106..0x40119a
        entry pc: 0x401106
        is global block
        symbol count: 2
        is contiguous

      [(block *) 0x504d9f0] 0x401106..0x40119a
        entry pc: 0x401106
        is static block
        symbol count: 1
        is contiguous

      [(block *) 0x504d9a0] 0x401106..0x40119a
        entry pc: 0x401106
        function: main
        is contiguous

      [(block *) 0x504d900] 0x401137..0x401166
        entry pc: 0x401137
        inline function: foo
        symbol count: 1
        is contiguous

      [(block *) 0x504d860] 0x401137..0x401165
        entry pc: 0x401137
        inline function: bar
        symbol count: 1
        is contiguous

  The command `maint info blocks` lists the symbol count for each block but doesn’t print the symbols themselves. The symbol names can be found using `maint print symbols` (see maint print symbols).

`maint print registers [file]` ¶
`maint print raw-registers [file]`
`maint print cooked-registers [file]`
`maint print register-groups [file]`
`maint print remote-registers [file]`

  Print GDB’s internal register data structures.

  The command `maint print raw-registers` includes the contents of the raw register cache; the command `maint print cooked-registers` includes the (cooked) value of all registers, including registers which aren’t available on the target nor visible to user; the command `maint print register-groups` includes the groups that each register is a member of; and the command `maint print remote-registers` includes the remote target’s register numbers and offsets in the ‘G’ packets, as well as an indication of which registers were included in the last stop reply packet received by GDB (see Stop Reply Packets). Please note that the list of registers included in a stop reply can change from one stop to the next.

  These commands take an optional parameter, a file name to which to write the information.

`maint print reggroups [file]` ¶

  Print GDB’s internal register group data structures. The optional argument file tells to what file to write the information.

  The register groups info looks like this:

      (gdb) maint print reggroups
       Group      Type
       general    user
       float      user
       all        user
       vector     user
       system     user
       save       internal
       restore    internal

`maint flush register-cache` ¶
`flushregs`

  Flush the contents of the register cache and as a consequence the frame cache. This command is useful when debugging issues related to register fetching, or frame unwinding. The command `flushregs` is deprecated in favor of `maint flush register-cache`.

`maint flush source-cache` ¶

  Flush GDB’s cache of source code file contents. After GDB reads a source file, and optionally applies styling (see Output Styling), the file contents are cached. This command clears that cache. The next time GDB wants to show lines from a source file, the content will be re-read.

  This command is useful when debugging issues related to source code styling. After flushing the cache any source code displayed by GDB will be re-read and re-styled.

`maint print objfiles [regexp]` ¶

  Print a dump of all known object files. If regexp is specified, only print object files whose names match regexp. For each object file, this command prints its name, address in memory, and all of its psymtabs and symtabs.

`maint print user-registers` ¶

  List all currently available user registers. User registers typically provide alternate names for actual hardware registers. They include the four “standard” registers `$fp`, `$pc`, `$sp`, and `$ps`. See standard registers. User registers can be used in expressions in the same way as the canonical register names, but only the latter are listed by the `info registers` and `maint print registers` commands.

`maint print section-scripts [regexp]` ¶

  Print a dump of scripts specified in the `.debug_gdb_section` section. If regexp is specified, only print scripts loaded by object files matching regexp. For each script, this command prints its name as specified in the objfile, and the full path if known. See The `.debug_gdb_scripts` section.

`maint print statistics` ¶

  This command prints, for each object file in the program, various data about that object file followed by the byte cache (bcache) statistics for the object file. The objfile data includes the number of minimal, partial, full, and stabs symbols, the number of types defined by the objfile, the number of as yet unexpanded psym tables, the number of line tables and string tables, and the amount of memory used by the various tables. The bcache statistics include the counts, sizes, and counts of duplicates of all and unique objects, max, average, and median entry size, total memory used and its overhead and savings, and various measures of the hash table size and chain lengths.

`maint print target-stack` ¶

  A target is an interface between the debugger and a particular kind of file or process. Targets can be stacked in strata, so that more than one target can potentially respond to a request. In particular, memory accesses will walk down the stack of targets until they find a target that is interested in handling that particular address.

  This command prints a short description of each layer that was pushed on the target stack, starting from the top layer down to the bottom one.

`maint print type expr` ¶

  Print the type chain for a type specified by expr. The argument can be either a type name or a symbol. If it is a symbol, the type of that symbol is described. The type chain produced by this command is a recursive definition of the data type as stored in GDB’s data structures, including its flags and contained types.

`maint print record-instruction` ¶
`maint print record-instruction N`

  print how GDB recorded a given instruction. If n is not positive number, it prints the values stored by the inferior before the n-th previous instruction was executed. If n is positive, print the values after the n-th following instruction is executed. If n is not given, 0 is assumed.

`maint selftest [-verbose] [filter]` ¶

  Run any self tests that were compiled in to GDB. This will print a message showing how many tests were run, and how many failed. If a filter is passed, only the tests with filter in their name will be ran. If `-verbose` is passed, the self tests can be more verbose.

`maint set selftest verbose` ¶
`maint show selftest verbose`

  Control whether self tests are run verbosely or not.

`maint info selftests` ¶

  List the selftests compiled in to GDB.

`maint set dwarf always-disassemble` ¶
`maint show dwarf always-disassemble`

  Control the behavior of `info address` when using DWARF debugging information.

  The default is `off`, which means that GDB should try to describe a variable’s location in an easily readable format. When `on`, GDB will instead display the DWARF location expression in an assembly-like format. Note that some locations are too complex for GDB to describe simply; in this case you will always see the disassembly form.

  Here is an example of the resulting disassembly:

      (gdb) info addr argc
      Symbol "argc" is a complex DWARF expression:
           1: DW_OP_fbreg 0

  For more information on these expressions, see the DWARF standard.

`maint set dwarf max-cache-age` ¶
`maint show dwarf max-cache-age`

  Control the DWARF compilation unit cache.

  In object files with inter-compilation-unit references, such as those produced by the GCC option ‘`-feliminate-dwarf2-dups`’, the DWARF reader needs to frequently refer to previously read compilation units. This setting controls how long a compilation unit will remain in the cache if it is not referenced. A higher limit means that cached compilation units will be stored in memory longer, and more total memory will be used. Setting it to zero disables caching, which will slow down GDB startup, but reduce memory consumption.

`maint set dwarf synchronous` ¶
`maint show dwarf synchronous`

  Control whether DWARF is read asynchronously.

  On hosts where threading is available, the DWARF reader is mostly asynchronous with respect to the rest of GDB. That is, the bulk of the reading is done in the background, and GDB will only pause for completion of this task when absolutely necessary.

  When this setting is enabled, GDB will instead wait for DWARF processing to complete before continuing.

  On hosts without threading, or where worker threads have been disabled at runtime, this setting has no effect, as DWARF reading is always done on the main thread, and is therefore always synchronous.

`maint set dwarf unwinders` ¶
`maint show dwarf unwinders`

  Control use of the DWARF frame unwinders.

  Many targets that support DWARF debugging use GDB’s DWARF frame unwinders to build the backtrace. Many of these targets will also have a second mechanism for building the backtrace for use in cases where DWARF information is not available, this second mechanism is often an analysis of a function’s prologue.

  In order to extend testing coverage of the second level stack unwinding mechanisms it is helpful to be able to disable the DWARF stack unwinders, this can be done with this switch.

  In normal use of GDB disabling the DWARF unwinders is not advisable, there are cases that are better handled through DWARF than prologue analysis, and the debug experience is likely to be better with the DWARF frame unwinders enabled.

  If DWARF frame unwinders are not supported for a particular target architecture, then enabling this flag does not cause them to be used.

`maint info frame-unwinders` ¶

  List the frame unwinders currently in effect, starting with the highest priority.

`maint set worker-threads` ¶
`maint show worker-threads`

  Control the number of worker threads that may be used by GDB. On capable hosts, GDB may use multiple threads to speed up certain CPU-intensive operations, such as demangling symbol names. While the number of threads used by GDB may vary, this command can be used to set an upper bound on this number. The default is `unlimited`, which lets GDB choose a reasonable number. Note that this only controls worker threads started by GDB itself; libraries used by GDB may start threads of their own.

`maint set profile` ¶
`maint show profile`

  Control profiling of GDB.

  Profiling will be disabled until you use the ‘`maint set profile`’ command to enable it. When you enable profiling, the system will begin collecting timing and execution count data; when you disable profiling or exit GDB, the results will be written to a log file. Remember that if you use profiling, GDB will overwrite the profiling log file (often called `gmon.out`). If you have a record of important profiling data in a `gmon.out` file, be sure to move it to a safe location.

  Configuring with ‘`--enable-profiling`’ arranges for GDB to be compiled with the ‘`-pg`’ compiler option.

`maint set show-debug-regs` ¶
`maint show show-debug-regs`

  Control whether to show variables that mirror the hardware debug registers. Use `on` to enable, `off` to disable. If enabled, the debug registers values are shown when GDB inserts or removes a hardware breakpoint or watchpoint, and when the inferior triggers a hardware-assisted breakpoint or watchpoint.

`maint set show-all-tib` ¶
`maint show show-all-tib`

  Control whether to show all non zero areas within a 1k block starting at thread local base, when using the ‘`info w32 thread-information-block`’ command.

`maint set target-async` ¶
`maint show target-async`

  This controls whether GDB targets operate in synchronous or asynchronous mode (see Background Execution). Normally the default is asynchronous, if it is available; but this can be changed to more easily debug problems occurring only in synchronous mode.

`maint set target-non-stop` ¶
`maint show target-non-stop`

  This controls whether GDB targets always operate in non-stop mode even if `set non-stop` is `off` (see Non-Stop Mode). The default is `auto`, meaning non-stop mode is enabled if supported by the target.

  `maint set target-non-stop auto`

    This is the default mode. GDB controls the target in non-stop mode if the target supports it.

  `maint set target-non-stop on`

    GDB controls the target in non-stop mode even if the target does not indicate support.

  `maint set target-non-stop off`

    GDB does not control the target in non-stop mode even if the target supports it.

`maint set tui-resize-message` ¶
`maint show tui-resize-message`

  Control whether GDB displays a message each time the terminal is resized when in TUI mode. The default is `off`, which means that GDB is silent during resizes. When `on`, GDB will display a message after a resize is completed; the message will include a number indicating how many times the terminal has been resized. This setting is intended for use by the test suite, where it would otherwise be difficult to determine when a resize and refresh has been completed.

`maint set tui-left-margin-verbose` ¶
`maint show tui-left-margin-verbose`

  Control whether the left margin of the TUI source and disassembly windows uses ‘`_`’ and ‘`0`’ at locations where otherwise there would be a space. The default is `off`, which means spaces are used. The setting is intended to make it clear where the left margin begins and ends, to avoid incorrectly interpreting a space as being part of the the left margin.

`maint set per-command` ¶
`maint show per-command`

  GDB can display the resources used by each command. This is useful in debugging performance problems.

  `maint set per-command space [on|off]`
  `maint show per-command space`

    Enable or disable the printing of the memory used by GDB for each command. If enabled, GDB will display how much memory each command took, following the command’s own output. This can also be requested by invoking GDB with the `--statistics` command-line switch (see Choosing Modes).

  `maint set per-command time [on|off]`
  `maint show per-command time`

    Enable or disable the printing of the execution time of GDB for each command. If enabled, GDB will display how much time it took to execute each command, following the command’s own output. Both CPU time and wallclock time are printed. Printing both is useful when trying to determine whether the cost is CPU or, e.g., disk/network latency. Note that the CPU time printed is for GDB only, it does not include the execution time of the inferior because there’s no mechanism currently to compute how much time was spent by GDB and how much time was spent by the program been debugged. This can also be requested by invoking GDB with the `--statistics` command-line switch (see Choosing Modes).

  `maint set per-command symtab [on|off]`
  `maint show per-command symtab`

    Enable or disable the printing of basic symbol table statistics for each command. If enabled, GDB will display the following information:

    1. number of symbol tables
    2. number of primary symbol tables
    3. number of blocks in the blockvector
`maint set check-libthread-db [on|off]` ¶
`maint show check-libthread-db`

  Control whether GDB should run integrity checks on inferior specific thread debugging libraries as they are loaded. The default is not to perform such checks. If any check fails GDB will unload the library and continue searching for a suitable candidate as described in set libthread-db-search-path. For more information about the tests, see maint check libthread-db.

`maint set gnu-source-highlight enabled [on|off]` ¶
`maint show gnu-source-highlight enabled`

  Control whether GDB should use the GNU Source Highlight library for applying styling to source code (see Output Styling). This will be ‘`on`’ by default if the GNU Source Highlight library is available. If the GNU Source Highlight library is not available, then this will be ‘`off`’ by default, and attempting to change this value to ‘`on`’ will give an error.

  If the GNU Source Highlight library is not being used, then GDB will use the Python Pygments package for source code styling, if it is available.

  This option is useful for debugging GDB’s use of the Pygments library when GDB is linked against the GNU Source Highlight library.

`maint set libopcodes-styling enabled [on|off]` ¶
`maint show libopcodes-styling enabled`

  Control whether GDB should use its builtin disassembler (`libopcodes`) to style disassembler output (see Output Styling). The builtin disassembler does not support styling for all architectures.

  When this option is ‘`off`’ the builtin disassembler will not be used for styling, GDB will fall back to using the Python Pygments package if possible.

  Trying to set this option ‘`on`’ for an architecture that the builtin disassembler is unable to style will give an error, otherwise, the builtin disassembler will be used to style disassembler output.

  This option is ‘`on`’ by default for supported architectures.

  This option is useful for debugging GDB’s use of the Pygments library when GDB is built for an architecture that supports styling with the builtin disassembler

`maint info screen` ¶

  Print various characteristics of the screen, such as various notions of width and height.

`maint space value` ¶

  An alias for `maint set per-command space`. A non-zero value enables it, zero disables it.

`maint time value` ¶

  An alias for `maint set per-command time`. A non-zero value enables it, zero disables it.

`maint translate-address [section] addr` ¶

  Find the symbol stored at the location specified by the address addr and an optional section name section. If found, GDB prints the name of the closest symbol and an offset from the symbol’s location to the specified address. This is similar to the `info address` command (see Examining the Symbol Table), except that this command also allows to find symbols in other sections.

  If section was not specified, the section in which the symbol was found is also printed. For dynamically linked executables, the name of executable or shared library containing the symbol is printed as well.

`maint test-options require-delimiter` ¶
`maint test-options unknown-is-error`
`maint test-options unknown-is-operand`

  These commands are used by the testsuite to validate the command options framework. The `require-delimiter` variant requires a double-dash delimiter to indicate end of options. The `unknown-is-error` and `unknown-is-operand` do not. The `unknown-is-error` variant throws an error on unknown option, while `unknown-is-operand` treats unknown options as the start of the command’s operands. When run, the commands output the result of the processed options. When completed, the commands store the internal result of completion in a variable exposed by the `maint show test-options-completion-result` command.

`maint show test-options-completion-result` ¶

  Shows the result of completing the `maint test-options` subcommands. This is used by the testsuite to validate completion support in the command options framework.

`maint set test-settings kind` ¶
`maint show test-settings kind`

  These are representative commands for each kind of setting type GDB supports. They are used by the testsuite for exercising the settings infrastructure.

`maint set backtrace-on-fatal-signal [on|off]` ¶
`maint show backtrace-on-fatal-signal`

  When this setting is `on`, if GDB itself terminates with a fatal signal (e.g. SIGSEGV), then a limited backtrace will be printed to the standard error stream. This backtrace can be used to help diagnose crashes within GDB in situations where a user is unable to share a corefile with the GDB developers.

  If the functionality to provide this backtrace is not available for the platform on which GDB is running then this feature will be `off` by default, and attempting to turn this feature on will give an error.

  For platforms that do support creating the backtrace this feature is `on` by default.

`maint wait-for-index-cache` ¶

  Wait until all pending writes to the index cache have completed. This is used by the test suite to avoid races when the index cache is being updated by a worker thread.

`maint with setting [value] [-- command]` ¶

  Like the `with` command, but works with `maintenance set` variables. This is used by the testsuite to exercise the `with` command’s infrastructure.

`maint ignore-probes [-v|-verbose] [provider [name [objfile]]]` ¶
`maint ignore-probes -reset`

  Set or reset the ignore-probes filter. The provider, name and objfile arguments are as in `enable probes` and `disable probes` (see enable probes). Only supported for SystemTap probes.

  Here’s an example of using `maint ignore-probes`:

      (gdb) maint ignore-probes -verbose libc ^longjmp$
      ignore-probes filter has been set to:
      PROVIDER: 'libc'
      PROBE_NAME: '^longjmp$'
      OBJNAME: ''
      (gdb) start
      <... more output ...>
      Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
      Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
      Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M

The following command is useful for non-interactive invocations of GDB, such as in the test suite.

`set watchdog nsec` ¶

  Set the maximum number of seconds GDB will wait for the target operation to finish. If this time expires, GDB reports and error and the command is aborted.

`show watchdog`

  Show the current setting of the target wait timeout.