Subversion Repositories or1k

This is gdb.info, produced by makeinfo version 4.1 from ./gdb.texinfo.

INFO-DIR-SECTION Programming & development tools.

START-INFO-DIR-ENTRY

* Gdb: (gdb).                     The GNU debugger.

END-INFO-DIR-ENTRY

   This file documents the GNU debugger GDB.

   This is the Ninth Edition, December 2001, of `Debugging with GDB:

the GNU Source-Level Debugger' for GDB Version 5.3.

   Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,

1998,

1999, 2000, 2001, 2002 Free Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.1 or

any later version published by the Free Software Foundation; with the

Invariant Sections being "Free Software" and "Free Software Needs Free

Documentation", with the Front-Cover Texts being "A GNU Manual," and

with the Back-Cover Texts as in (a) below.

   (a) The Free Software Foundation's Back-Cover Text is: "You have

freedom to copy and modify this GNU Manual, like GNU software.  Copies

published by the Free Software Foundation raise funds for GNU

development."

File: gdb.info,  Node: Value Annotations,  Next: Frame Annotations,  Prev: Server Prefix,  Up: Annotations

Values

======

   When a value is printed in various contexts, GDB uses annotations to

delimit the value from the surrounding text.

   If a value is printed using `print' and added to the value history,

the annotation looks like

     ^Z^Zvalue-history-begin HISTORY-NUMBER VALUE-FLAGS

     HISTORY-STRING

     ^Z^Zvalue-history-value

     THE-VALUE

     ^Z^Zvalue-history-end

where HISTORY-NUMBER is the number it is getting in the value history,

HISTORY-STRING is a string, such as `$5 = ', which introduces the value

to the user, THE-VALUE is the output corresponding to the value itself,

and VALUE-FLAGS is `*' for a value which can be dereferenced and `-'

for a value which cannot.

   If the value is not added to the value history (it is an invalid

float or it is printed with the `output' command), the annotation is

similar:

     ^Z^Zvalue-begin VALUE-FLAGS

     THE-VALUE

     ^Z^Zvalue-end

   When GDB prints an argument to a function (for example, in the output

from the `backtrace' command), it annotates it as follows:

     ^Z^Zarg-begin

     ARGUMENT-NAME

     ^Z^Zarg-name-end

     SEPARATOR-STRING

     ^Z^Zarg-value VALUE-FLAGS

     THE-VALUE

     ^Z^Zarg-end

where ARGUMENT-NAME is the name of the argument, SEPARATOR-STRING is

text which separates the name from the value for the user's benefit

(such as `='), and VALUE-FLAGS and THE-VALUE have the same meanings as

in a `value-history-begin' annotation.

   When printing a structure, GDB annotates it as follows:

     ^Z^Zfield-begin VALUE-FLAGS

     FIELD-NAME

     ^Z^Zfield-name-end

     SEPARATOR-STRING

     ^Z^Zfield-value

     THE-VALUE

     ^Z^Zfield-end

where FIELD-NAME is the name of the field, SEPARATOR-STRING is text

which separates the name from the value for the user's benefit (such as

`='), and VALUE-FLAGS and THE-VALUE have the same meanings as in a

`value-history-begin' annotation.

   When printing an array, GDB annotates it as follows:

     ^Z^Zarray-section-begin ARRAY-INDEX VALUE-FLAGS

where ARRAY-INDEX is the index of the first element being annotated and

VALUE-FLAGS has the same meaning as in a `value-history-begin'

annotation.  This is followed by any number of elements, where is

element can be either a single element:

     `,' WHITESPACE         ; omitted for the first element

     THE-VALUE

     ^Z^Zelt

   or a repeated element

     `,' WHITESPACE         ; omitted for the first element

     THE-VALUE

     ^Z^Zelt-rep NUMBER-OF-REPITITIONS

     REPETITION-STRING

     ^Z^Zelt-rep-end

   In both cases, THE-VALUE is the output for the value of the element

and WHITESPACE can contain spaces, tabs, and newlines.  In the repeated

case, NUMBER-OF-REPITITONS is the number of consecutive array elements

which contain that value, and REPETITION-STRING is a string which is

designed to convey to the user that repitition is being depicted.

   Once all the array elements have been output, the array annotation is

ended with

     ^Z^Zarray-section-end

File: gdb.info,  Node: Frame Annotations,  Next: Displays,  Prev: Value Annotations,  Up: Annotations

Frames

======

   Whenever GDB prints a frame, it annotates it.  For example, this

applies to frames printed when GDB stops, output from commands such as

`backtrace' or `up', etc.

   The frame annotation begins with

     ^Z^Zframe-begin LEVEL ADDRESS

     LEVEL-STRING

where LEVEL is the number of the frame (0 is the innermost frame, and

other frames have positive numbers), ADDRESS is the address of the code

executing in that frame, and LEVEL-STRING is a string designed to

convey the level to the user.  ADDRESS is in the form `0x' followed by

one or more lowercase hex digits (note that this does not depend on the

language).  The frame ends with

     ^Z^Zframe-end

   Between these annotations is the main body of the frame, which can

consist of

   *      ^Z^Zfunction-call

          FUNCTION-CALL-STRING

     where FUNCTION-CALL-STRING is text designed to convey to the user

     that this frame is associated with a function call made by GDB to a

     function in the program being debugged.

   *      ^Z^Zsignal-handler-caller

          SIGNAL-HANDLER-CALLER-STRING

     where SIGNAL-HANDLER-CALLER-STRING is text designed to convey to

     the user that this frame is associated with whatever mechanism is

     used by this operating system to call a signal handler (it is the

     frame which calls the signal handler, not the frame for the signal

     handler itself).

   * A normal frame.

     This can optionally (depending on whether this is thought of as

     interesting information for the user to see) begin with

          ^Z^Zframe-address

          ADDRESS

          ^Z^Zframe-address-end

          SEPARATOR-STRING

     where ADDRESS is the address executing in the frame (the same

     address as in the `frame-begin' annotation, but printed in a form

     which is intended for user consumption--in particular, the syntax

     varies depending on the language), and SEPARATOR-STRING is a string

     intended to separate this address from what follows for the user's

     benefit.

     Then comes

          ^Z^Zframe-function-name

          FUNCTION-NAME

          ^Z^Zframe-args

          ARGUMENTS

     where FUNCTION-NAME is the name of the function executing in the

     frame, or `??' if not known, and ARGUMENTS are the arguments to

     the frame, with parentheses around them (each argument is annotated

     individually as well, *note Value Annotations::).

     If source information is available, a reference to it is then

     printed:

          ^Z^Zframe-source-begin

          SOURCE-INTRO-STRING

          ^Z^Zframe-source-file

          FILENAME

          ^Z^Zframe-source-file-end

          :

          ^Z^Zframe-source-line

          LINE-NUMBER

          ^Z^Zframe-source-end

     where SOURCE-INTRO-STRING separates for the user's benefit the

     reference from the text which precedes it, FILENAME is the name of

     the source file, and LINE-NUMBER is the line number within that

     file (the first line is line 1).

     If GDB prints some information about where the frame is from (which

     library, which load segment, etc.; currently only done on the

     RS/6000), it is annotated with

          ^Z^Zframe-where

          INFORMATION

     Then, if source is to actually be displayed for this frame (for

     example, this is not true for output from the `backtrace'

     command), then a `source' annotation (*note Source Annotations::)

     is displayed.  Unlike most annotations, this is output instead of

     the normal text which would be output, not in addition.

File: gdb.info,  Node: Displays,  Next: Prompting,  Prev: Frame Annotations,  Up: Annotations

Displays

========

   When GDB is told to display something using the `display' command,

the results of the display are annotated:

     ^Z^Zdisplay-begin

     NUMBER

     ^Z^Zdisplay-number-end

     NUMBER-SEPARATOR

     ^Z^Zdisplay-format

     FORMAT

     ^Z^Zdisplay-expression

     EXPRESSION

     ^Z^Zdisplay-expression-end

     EXPRESSION-SEPARATOR

     ^Z^Zdisplay-value

     VALUE

     ^Z^Zdisplay-end

where NUMBER is the number of the display, NUMBER-SEPARATOR is intended

to separate the number from what follows for the user, FORMAT includes

information such as the size, format, or other information about how

the value is being displayed, EXPRESSION is the expression being

displayed, EXPRESSION-SEPARATOR is intended to separate the expression

from the text that follows for the user, and VALUE is the actual value

being displayed.

File: gdb.info,  Node: Prompting,  Next: Errors,  Prev: Displays,  Up: Annotations

Annotation for GDB Input

========================

   When GDB prompts for input, it annotates this fact so it is possible

to know when to send output, when the output from a given command is

over, etc.

   Different kinds of input each have a different "input type".  Each

input type has three annotations: a `pre-' annotation, which denotes

the beginning of any prompt which is being output, a plain annotation,

which denotes the end of the prompt, and then a `post-' annotation

which denotes the end of any echo which may (or may not) be associated

with the input.  For example, the `prompt' input type features the

following annotations:

     ^Z^Zpre-prompt

     ^Z^Zprompt

     ^Z^Zpost-prompt

   The input types are

`prompt'

     When GDB is prompting for a command (the main GDB prompt).

`commands'

     When GDB prompts for a set of commands, like in the `commands'

     command.  The annotations are repeated for each command which is

     input.

`overload-choice'

     When GDB wants the user to select between various overloaded

     functions.

`query'

     When GDB wants the user to confirm a potentially dangerous

     operation.

`prompt-for-continue'

     When GDB is asking the user to press return to continue.  Note:

     Don't expect this to work well; instead use `set height 0' to

     disable prompting.  This is because the counting of lines is buggy

     in the presence of annotations.

File: gdb.info,  Node: Errors,  Next: Breakpoint Info,  Prev: Prompting,  Up: Annotations

Errors

======

     ^Z^Zquit

   This annotation occurs right before GDB responds to an interrupt.

     ^Z^Zerror

   This annotation occurs right before GDB responds to an error.

   Quit and error annotations indicate that any annotations which GDB

was in the middle of may end abruptly.  For example, if a

`value-history-begin' annotation is followed by a `error', one cannot

expect to receive the matching `value-history-end'.  One cannot expect

not to receive it either, however; an error annotation does not

necessarily mean that GDB is immediately returning all the way to the

top level.

   A quit or error annotation may be preceded by

     ^Z^Zerror-begin

   Any output between that and the quit or error annotation is the error

message.

   Warning messages are not yet annotated.

File: gdb.info,  Node: Breakpoint Info,  Next: Invalidation,  Prev: Errors,  Up: Annotations

Information on Breakpoints

==========================

   The output from the `info breakpoints' command is annotated as

follows:

     ^Z^Zbreakpoints-headers

     HEADER-ENTRY

     ^Z^Zbreakpoints-table

where HEADER-ENTRY has the same syntax as an entry (see below) but

instead of containing data, it contains strings which are intended to

convey the meaning of each field to the user.  This is followed by any

number of entries.  If a field does not apply for this entry, it is

omitted.  Fields may contain trailing whitespace.  Each entry consists

of:

     ^Z^Zrecord

     ^Z^Zfield 0

     NUMBER

     ^Z^Zfield 1

     TYPE

     ^Z^Zfield 2

     DISPOSITION

     ^Z^Zfield 3

     ENABLE

     ^Z^Zfield 4

     ADDRESS

     ^Z^Zfield 5

     WHAT

     ^Z^Zfield 6

     FRAME

     ^Z^Zfield 7

     CONDITION

     ^Z^Zfield 8

     IGNORE-COUNT

     ^Z^Zfield 9

     COMMANDS

   Note that ADDRESS is intended for user consumption--the syntax

varies depending on the language.

   The output ends with

     ^Z^Zbreakpoints-table-end

File: gdb.info,  Node: Invalidation,  Next: Annotations for Running,  Prev: Breakpoint Info,  Up: Annotations

Invalidation Notices

====================

   The following annotations say that certain pieces of state may have

changed.

`^Z^Zframes-invalid'

     The frames (for example, output from the `backtrace' command) may

     have changed.

`^Z^Zbreakpoints-invalid'

     The breakpoints may have changed.  For example, the user just

     added or deleted a breakpoint.

File: gdb.info,  Node: Annotations for Running,  Next: Source Annotations,  Prev: Invalidation,  Up: Annotations

Running the Program

===================

   When the program starts executing due to a GDB command such as

`step' or `continue',

     ^Z^Zstarting

   is output.  When the program stops,

     ^Z^Zstopped

   is output.  Before the `stopped' annotation, a variety of

annotations describe how the program stopped.

`^Z^Zexited EXIT-STATUS'

     The program exited, and EXIT-STATUS is the exit status (zero for

     successful exit, otherwise nonzero).

`^Z^Zsignalled'

     The program exited with a signal.  After the `^Z^Zsignalled', the

     annotation continues:

          INTRO-TEXT

          ^Z^Zsignal-name

          NAME

          ^Z^Zsignal-name-end

          MIDDLE-TEXT

          ^Z^Zsignal-string

          STRING

          ^Z^Zsignal-string-end

          END-TEXT

     where NAME is the name of the signal, such as `SIGILL' or

     `SIGSEGV', and STRING is the explanation of the signal, such as

     `Illegal Instruction' or `Segmentation fault'.  INTRO-TEXT,

     MIDDLE-TEXT, and END-TEXT are for the user's benefit and have no

     particular format.

`^Z^Zsignal'

     The syntax of this annotation is just like `signalled', but GDB is

     just saying that the program received the signal, not that it was

     terminated with it.

`^Z^Zbreakpoint NUMBER'

     The program hit breakpoint number NUMBER.

`^Z^Zwatchpoint NUMBER'

     The program hit watchpoint number NUMBER.

File: gdb.info,  Node: Source Annotations,  Next: TODO,  Prev: Annotations for Running,  Up: Annotations

Displaying Source

=================

   The following annotation is used instead of displaying source code:

     ^Z^Zsource FILENAME:LINE:CHARACTER:MIDDLE:ADDR

   where FILENAME is an absolute file name indicating which source

file, LINE is the line number within that file (where 1 is the first

line in the file), CHARACTER is the character position within the file

(where 0 is the first character in the file) (for most debug formats

this will necessarily point to the beginning of a line), MIDDLE is

`middle' if ADDR is in the middle of the line, or `beg' if ADDR is at

the beginning of the line, and ADDR is the address in the target

program associated with the source which is being displayed.  ADDR is

in the form `0x' followed by one or more lowercase hex digits (note

that this does not depend on the language).

File: gdb.info,  Node: TODO,  Prev: Source Annotations,  Up: Annotations

Annotations We Might Want in the Future

=======================================

    - target-invalid

      the target might have changed (registers, heap contents, or

      execution status).  For performance, we might eventually want

      to hit `registers-invalid' and `all-registers-invalid' with

      greater precision

    - systematic annotation for set/show parameters (including

      invalidation notices).

    - similarly, `info' returns a list of candidates for invalidation

      notices.

File: gdb.info,  Node: GDB/MI,  Next: GDB Bugs,  Prev: Annotations,  Up: Top

The GDB/MI Interface

********************

Function and Purpose

====================

   GDB/MI is a line based machine oriented text interface to GDB.  It is

specifically intended to support the development of systems which use

the debugger as just one small component of a larger system.

   This chapter is a specification of the GDB/MI interface.  It is

written in the form of a reference manual.

   Note that GDB/MI is still under construction, so some of the

features described below are incomplete and subject to change.

Notation and Terminology

========================

   This chapter uses the following notation:

   * `|' separates two alternatives.

   * `[ SOMETHING ]' indicates that SOMETHING is optional: it may or

     may not be given.

   * `( GROUP )*' means that GROUP inside the parentheses may repeat

     zero or more times.

   * `( GROUP )+' means that GROUP inside the parentheses may repeat

     one or more times.

   * `"STRING"' means a literal STRING.

Acknowledgments

===============

   In alphabetic order: Andrew Cagney, Fernando Nasser, Stan Shebs and

Elena Zannoni.

* Menu:

* GDB/MI Command Syntax::

* GDB/MI Compatibility with CLI::

* GDB/MI Output Records::

* GDB/MI Command Description Format::

* GDB/MI Breakpoint Table Commands::

* GDB/MI Data Manipulation::

* GDB/MI Program Control::

* GDB/MI Miscellaneous Commands::

* GDB/MI Stack Manipulation::

* GDB/MI Symbol Query::

* GDB/MI Target Manipulation::

* GDB/MI Thread Commands::

* GDB/MI Tracepoint Commands::

* GDB/MI Variable Objects::

File: gdb.info,  Node: GDB/MI Command Syntax,  Next: GDB/MI Compatibility with CLI,  Up: GDB/MI

GDB/MI Command Syntax

=====================

* Menu:

* GDB/MI Input Syntax::

* GDB/MI Output Syntax::

* GDB/MI Simple Examples::

File: gdb.info,  Node: GDB/MI Input Syntax,  Next: GDB/MI Output Syntax,  Up: GDB/MI Command Syntax

GDB/MI Input Syntax

-------------------

`COMMAND ==>'

     `CLI-COMMAND | MI-COMMAND'

`CLI-COMMAND ==>'

     `[ TOKEN ] CLI-COMMAND NL', where CLI-COMMAND is any existing GDB

     CLI command.

`MI-COMMAND ==>'

     `[ TOKEN ] "-" OPERATION ( " " OPTION )* `[' " --" `]' ( " "

     PARAMETER )* NL'

`TOKEN ==>'

     "any sequence of digits"

`OPTION ==>'

     `"-" PARAMETER [ " " PARAMETER ]'

`PARAMETER ==>'

     `NON-BLANK-SEQUENCE | C-STRING'

`OPERATION ==>'

     _any of the operations described in this chapter_

`NON-BLANK-SEQUENCE ==>'

     _anything, provided it doesn't contain special characters such as

     "-", NL, """ and of course " "_

`C-STRING ==>'

     `""" SEVEN-BIT-ISO-C-STRING-CONTENT """'

`NL ==>'

     `CR | CR-LF'

Notes:

   * The CLI commands are still handled by the MI interpreter; their

     output is described below.

   * The `TOKEN', when present, is passed back when the command

     finishes.

   * Some MI commands accept optional arguments as part of the parameter

     list.  Each option is identified by a leading `-' (dash) and may be

     followed by an optional argument parameter.  Options occur first

     in the parameter list and can be delimited from normal parameters

     using `--' (this is useful when some parameters begin with a dash).

   Pragmatics:

   * We want easy access to the existing CLI syntax (for debugging).

   * We want it to be easy to spot a MI operation.

File: gdb.info,  Node: GDB/MI Output Syntax,  Next: GDB/MI Simple Examples,  Prev: GDB/MI Input Syntax,  Up: GDB/MI Command Syntax

GDB/MI Output Syntax

--------------------

   The output from GDB/MI consists of zero or more out-of-band records

followed, optionally, by a single result record.  This result record is

for the most recent command.  The sequence of output records is

terminated by `(gdb)'.

   If an input command was prefixed with a `TOKEN' then the

corresponding output for that command will also be prefixed by that same

TOKEN.

`OUTPUT ==>'

     `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL'

`RESULT-RECORD ==>'

     ` [ TOKEN ] "^" RESULT-CLASS ( "," RESULT )* NL'

`OUT-OF-BAND-RECORD ==>'

     `ASYNC-RECORD | STREAM-RECORD'

`ASYNC-RECORD ==>'

     `EXEC-ASYNC-OUTPUT | STATUS-ASYNC-OUTPUT | NOTIFY-ASYNC-OUTPUT'

`EXEC-ASYNC-OUTPUT ==>'

     `[ TOKEN ] "*" ASYNC-OUTPUT'

`STATUS-ASYNC-OUTPUT ==>'

     `[ TOKEN ] "+" ASYNC-OUTPUT'

`NOTIFY-ASYNC-OUTPUT ==>'

     `[ TOKEN ] "=" ASYNC-OUTPUT'

`ASYNC-OUTPUT ==>'

     `ASYNC-CLASS ( "," RESULT )* NL'

`RESULT-CLASS ==>'

     `"done" | "running" | "connected" | "error" | "exit"'

`ASYNC-CLASS ==>'

     `"stopped" | OTHERS' (where OTHERS will be added depending on the

     needs--this is still in development).

`RESULT ==>'

     ` VARIABLE "=" VALUE'

`VARIABLE ==>'

     ` STRING '

`VALUE ==>'

     ` CONST | TUPLE | LIST '

`CONST ==>'

     `C-STRING'

`TUPLE ==>'

     ` "{}" | "{" RESULT ( "," RESULT )* "}" '

`LIST ==>'

     ` "[]" | "[" VALUE ( "," VALUE )* "]" | "[" RESULT ( "," RESULT )*

     "]" '

`STREAM-RECORD ==>'

     `CONSOLE-STREAM-OUTPUT | TARGET-STREAM-OUTPUT | LOG-STREAM-OUTPUT'

`CONSOLE-STREAM-OUTPUT ==>'

     `"~" C-STRING'

`TARGET-STREAM-OUTPUT ==>'

     `"@" C-STRING'

`LOG-STREAM-OUTPUT ==>'

     `"&" C-STRING'

`NL ==>'

     `CR | CR-LF'

`TOKEN ==>'

     _any sequence of digits_.

Notes:

   * All output sequences end in a single line containing a period.

   * The `TOKEN' is from the corresponding request.  If an execution

     command is interrupted by the `-exec-interrupt' command, the TOKEN

     associated with the `*stopped' message is the one of the original

     execution command, not the one of the interrupt command.

   * STATUS-ASYNC-OUTPUT contains on-going status information about the

     progress of a slow operation.  It can be discarded.  All status

     output is prefixed by `+'.

   * EXEC-ASYNC-OUTPUT contains asynchronous state change on the target

     (stopped, started, disappeared).  All async output is prefixed by

     `*'.

   * NOTIFY-ASYNC-OUTPUT contains supplementary information that the

     client should handle (e.g., a new breakpoint information).  All

     notify output is prefixed by `='.

   * CONSOLE-STREAM-OUTPUT is output that should be displayed as is in

     the console.  It is the textual response to a CLI command.  All

     the console output is prefixed by `~'.

   * TARGET-STREAM-OUTPUT is the output produced by the target program.

     All the target output is prefixed by `@'.

   * LOG-STREAM-OUTPUT is output text coming from GDB's internals, for

     instance messages that should be displayed as part of an error

     log.  All the log output is prefixed by `&'.

   * New GDB/MI commands should only output LISTS containing VALUES.

   *Note GDB/MI Stream Records: GDB/MI Stream Records, for more details

about the various output records.

File: gdb.info,  Node: GDB/MI Simple Examples,  Prev: GDB/MI Output Syntax,  Up: GDB/MI Command Syntax

Simple Examples of GDB/MI Interaction

-------------------------------------

   This subsection presents several simple examples of interaction using

the GDB/MI interface.  In these examples, `->' means that the following

line is passed to GDB/MI as input, while `<-' means the output received

from GDB/MI.

Target Stop

...........

   Here's an example of stopping the inferior process:

     -> -stop

     <- (gdb)

and later:

     <- *stop,reason="stop",address="0x123",source="a.c:123"

     <- (gdb)

Simple CLI Command

..................

   Here's an example of a simple CLI command being passed through

GDB/MI and on to the CLI.

     -> print 1+2

     <- &"print 1+2\n"

     <- ~"$1 = 3\n"

     <- ^done

     <- (gdb)

Command With Side Effects

.........................

     -> -symbol-file xyz.exe

     <- *breakpoint,nr="3",address="0x123",source="a.c:123"

     <- (gdb)

A Bad Command

.............

   Here's what happens if you pass a non-existent command:

     -> -rubbish

     <- ^error,msg="Undefined MI command: rubbish"

     <- (gdb)

File: gdb.info,  Node: GDB/MI Compatibility with CLI,  Next: GDB/MI Output Records,  Prev: GDB/MI Command Syntax,  Up: GDB/MI

GDB/MI Compatibility with CLI

=============================

   To help users familiar with GDB's existing CLI interface, GDB/MI

accepts existing CLI commands.  As specified by the syntax, such

commands can be directly entered into the GDB/MI interface and GDB will

respond.

   This mechanism is provided as an aid to developers of GDB/MI clients

and not as a reliable interface into the CLI.  Since the command is

being interpreteted in an environment that assumes GDB/MI behaviour,

the exact output of such commands is likely to end up being an

un-supported hybrid of GDB/MI and CLI output.

File: gdb.info,  Node: GDB/MI Output Records,  Next: GDB/MI Command Description Format,  Prev: GDB/MI Compatibility with CLI,  Up: GDB/MI

GDB/MI Output Records

=====================

* Menu:

* GDB/MI Result Records::

* GDB/MI Stream Records::

* GDB/MI Out-of-band Records::

File: gdb.info,  Node: GDB/MI Result Records,  Next: GDB/MI Stream Records,  Up: GDB/MI Output Records

GDB/MI Result Records

---------------------

   In addition to a number of out-of-band notifications, the response

to a GDB/MI command includes one of the following result indications:

`"^done" [ "," RESULTS ]'

     The synchronous operation was successful, `RESULTS' are the return

     values.

`"^running"'

     The asynchronous operation was successfully started.  The target is

     running.

`"^error" "," C-STRING'

     The operation failed.  The `C-STRING' contains the corresponding

     error message.

File: gdb.info,  Node: GDB/MI Stream Records,  Next: GDB/MI Out-of-band Records,  Prev: GDB/MI Result Records,  Up: GDB/MI Output Records

GDB/MI Stream Records

---------------------

   GDB internally maintains a number of output streams: the console, the

target, and the log.  The output intended for each of these streams is

funneled through the GDB/MI interface using "stream records".

   Each stream record begins with a unique "prefix character" which

identifies its stream (*note GDB/MI Output Syntax: GDB/MI Output

Syntax.).  In addition to the prefix, each stream record contains a

`STRING-OUTPUT'.  This is either raw text (with an implicit new line)

or a quoted C string (which does not contain an implicit newline).

`"~" STRING-OUTPUT'

     The console output stream contains text that should be displayed

     in the CLI console window.  It contains the textual responses to

     CLI commands.

`"@" STRING-OUTPUT'

     The target output stream contains any textual output from the

     running target.

`"&" STRING-OUTPUT'

     The log stream contains debugging messages being produced by GDB's

     internals.

File: gdb.info,  Node: GDB/MI Out-of-band Records,  Prev: GDB/MI Stream Records,  Up: GDB/MI Output Records

GDB/MI Out-of-band Records

--------------------------

   "Out-of-band" records are used to notify the GDB/MI client of

additional changes that have occurred.  Those changes can either be a

consequence of GDB/MI (e.g., a breakpoint modified) or a result of

target activity (e.g., target stopped).

   The following is a preliminary list of possible out-of-band records.

`"*" "stop"'

File: gdb.info,  Node: GDB/MI Command Description Format,  Next: GDB/MI Breakpoint Table Commands,  Prev: GDB/MI Output Records,  Up: GDB/MI

GDB/MI Command Description Format

=================================

   The remaining sections describe blocks of commands.  Each block of

commands is laid out in a fashion similar to this section.

   Note the the line breaks shown in the examples are here only for

readability.  They don't appear in the real output.  Also note that the

commands with a non-available example (N.A.) are not yet implemented.

Motivation

----------

   The motivation for this collection of commands.

Introduction

------------

   A brief introduction to this collection of commands as a whole.

Commands

--------

   For each command in the block, the following is described:

Synopsis

........

      -command ARGS...

GDB Command

...........

   The corresponding GDB CLI command.

Result

......

Out-of-band

...........

Notes

.....

Example

.......