OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [gdb-5.3/] [gdb/] [doc/] [gdb.info-10] - Rev 1765

Compare with Previous | Blame | View Log

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
.......


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

GDB/MI Breakpoint table commands
================================

   This section documents GDB/MI commands for manipulating breakpoints.

The `-break-after' Command
--------------------------

Synopsis
........

      -break-after NUMBER COUNT

   The breakpoint number NUMBER is not in effect until it has been hit
COUNT times.  To see how this is reflected in the output of the
`-break-list' command, see the description of the `-break-list' command
below.

GDB Command
...........

   The corresponding GDB command is `ignore'.

Example
.......

     (gdb)
     -break-insert main
     ^done,bkpt={number="1",addr="0x000100d0",file="hello.c",line="5"}
     (gdb)
     -break-after 1 3
     ~
     ^done
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="1",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
     addr="0x000100d0",func="main",file="hello.c",line="5",times="0",
     ignore="3"}]}
     (gdb)

The `-break-condition' Command
------------------------------

Synopsis
........

      -break-condition NUMBER EXPR

   Breakpoint NUMBER will stop the program only if the condition in
EXPR is true.  The condition becomes part of the `-break-list' output
(see the description of the `-break-list' command below).

GDB Command
...........

   The corresponding GDB command is `condition'.

Example
.......

     (gdb)
     -break-condition 1 1
     ^done
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="1",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
     addr="0x000100d0",func="main",file="hello.c",line="5",cond="1",
     times="0",ignore="3"}]}
     (gdb)

The `-break-delete' Command
---------------------------

Synopsis
........

      -break-delete ( BREAKPOINT )+

   Delete the breakpoint(s) whose number(s) are specified in the
argument list.  This is obviously reflected in the breakpoint list.

GDB command
...........

   The corresponding GDB command is `delete'.

Example
.......

     (gdb)
     -break-delete 1
     ^done
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="0",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[]}
     (gdb)

The `-break-disable' Command
----------------------------

Synopsis
........

      -break-disable ( BREAKPOINT )+

   Disable the named BREAKPOINT(s).  The field `enabled' in the break
list is now set to `n' for the named BREAKPOINT(s).

GDB Command
...........

   The corresponding GDB command is `disable'.

Example
.......

     (gdb)
     -break-disable 2
     ^done
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="1",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="2",type="breakpoint",disp="keep",enabled="n",
     addr="0x000100d0",func="main",file="hello.c",line="5",times="0"}]}
     (gdb)

The `-break-enable' Command
---------------------------

Synopsis
........

      -break-enable ( BREAKPOINT )+

   Enable (previously disabled) BREAKPOINT(s).

GDB Command
...........

   The corresponding GDB command is `enable'.

Example
.......

     (gdb)
     -break-enable 2
     ^done
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="1",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="2",type="breakpoint",disp="keep",enabled="y",
     addr="0x000100d0",func="main",file="hello.c",line="5",times="0"}]}
     (gdb)

The `-break-info' Command
-------------------------

Synopsis
........

      -break-info BREAKPOINT

   Get information about a single breakpoint.

GDB command
...........

   The corresponding GDB command is `info break BREAKPOINT'.

Example
.......

   N.A.

The `-break-insert' Command
---------------------------

Synopsis
........

      -break-insert [ -t ] [ -h ] [ -r ]
         [ -c CONDITION ] [ -i IGNORE-COUNT ]
         [ -p THREAD ] [ LINE | ADDR ]

If specified, LINE, can be one of:

   * function

   * filename:linenum

   * filename:function

   * *address

   The possible optional parameters of this command are:

`-t'
     Insert a tempoary breakpoint.

`-h'
     Insert a hardware breakpoint.

`-c CONDITION'
     Make the breakpoint conditional on CONDITION.

`-i IGNORE-COUNT'
     Initialize the IGNORE-COUNT.

`-r'
     Insert a regular breakpoint in all the functions whose names match
     the given regular expression.  Other flags are not applicable to
     regular expresson.

Result
......

   The result is in the form:

      ^done,bkptno="NUMBER",func="FUNCNAME",
       file="FILENAME",line="LINENO"

where NUMBER is the GDB number for this breakpoint, FUNCNAME is the
name of the function where the breakpoint was inserted, FILENAME is the
name of the source file which contains this function, and LINENO is the
source line number within that file.

   Note: this format is open to change.

GDB Command
...........

   The corresponding GDB commands are `break', `tbreak', `hbreak',
`thbreak', and `rbreak'.

Example
.......

     (gdb)
     -break-insert main
     ^done,bkpt={number="1",addr="0x0001072c",file="recursive2.c",line="4"}
     (gdb)
     -break-insert -t foo
     ^done,bkpt={number="2",addr="0x00010774",file="recursive2.c",line="11"}
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="2",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
     addr="0x0001072c", func="main",file="recursive2.c",line="4",times="0"},
     bkpt={number="2",type="breakpoint",disp="del",enabled="y",
     addr="0x00010774",func="foo",file="recursive2.c",line="11",times="0"}]}
     (gdb)
     -break-insert -r foo.*
     ~int foo(int, int);
     ^done,bkpt={number="3",addr="0x00010774",file="recursive2.c",line="11"}
     (gdb)

The `-break-list' Command
-------------------------

Synopsis
........

      -break-list

   Displays the list of inserted breakpoints, showing the following
fields:

`Number'
     number of the breakpoint

`Type'
     type of the breakpoint: `breakpoint' or `watchpoint'

`Disposition'
     should the breakpoint be deleted or disabled when it is hit: `keep'
     or `nokeep'

`Enabled'
     is the breakpoint enabled or no: `y' or `n'

`Address'
     memory location at which the breakpoint is set

`What'
     logical location of the breakpoint, expressed by function name,
     file name, line number

`Times'
     number of times the breakpoint has been hit

   If there are no breakpoints or watchpoints, the `BreakpointTable'
`body' field is an empty list.

GDB Command
...........

   The corresponding GDB command is `info break'.

Example
.......

     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="2",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
     addr="0x000100d0",func="main",file="hello.c",line="5",times="0"},
     bkpt={number="2",type="breakpoint",disp="keep",enabled="y",
     addr="0x00010114",func="foo",file="hello.c",line="13",times="0"}]}
     (gdb)

   Here's an example of the result when there are no breakpoints:

     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="0",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[]}
     (gdb)

The `-break-watch' Command
--------------------------

Synopsis
........

      -break-watch [ -a | -r ]

   Create a watchpoint.  With the `-a' option it will create an
"access" watchpoint, i.e. a watchpoint that triggers either on a read
from or on a write to the memory location.  With the `-r' option, the
watchpoint created is a "read" watchpoint, i.e. it will trigger only
when the memory location is accessed for reading.  Without either of
the options, the watchpoint created is a regular watchpoint, i.e. it
will trigger when the memory location is accessed for writing.  *Note
Setting watchpoints: Set Watchpoints.

   Note that `-break-list' will report a single list of watchpoints and
breakpoints inserted.

GDB Command
...........

   The corresponding GDB commands are `watch', `awatch', and `rwatch'.

Example
.......

   Setting a watchpoint on a variable in the `main' function:

     (gdb)
     -break-watch x
     ^done,wpt={number="2",exp="x"}
     (gdb)
     -exec-continue
     ^running
     ^done,reason="watchpoint-trigger",wpt={number="2",exp="x"},
     value={old="-268439212",new="55"},
     frame={func="main",args=[],file="recursive2.c",line="5"}
     (gdb)

   Setting a watchpoint on a variable local to a function.  GDB will
stop the program execution twice: first for the variable changing
value, then for the watchpoint going out of scope.

     (gdb)
     -break-watch C
     ^done,wpt={number="5",exp="C"}
     (gdb)
     -exec-continue
     ^running
     ^done,reason="watchpoint-trigger",
     wpt={number="5",exp="C"},value={old="-276895068",new="3"},
     frame={func="callee4",args=[],
     file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="13"}
     (gdb)
     -exec-continue
     ^running
     ^done,reason="watchpoint-scope",wpnum="5",
     frame={func="callee3",args=[{name="strarg",
     value="0x11940 \"A string argument.\""}],
     file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="18"}
     (gdb)

   Listing breakpoints and watchpoints, at different points in the
program execution.  Note that once the watchpoint goes out of scope, it
is deleted.

     (gdb)
     -break-watch C
     ^done,wpt={number="2",exp="C"}
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="2",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
     addr="0x00010734",func="callee4",
     file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8",times="1"},
     bkpt={number="2",type="watchpoint",disp="keep",
     enabled="y",addr="",what="C",times="0"}]}
     (gdb)
     -exec-continue
     ^running
     ^done,reason="watchpoint-trigger",wpt={number="2",exp="C"},
     value={old="-276895068",new="3"},
     frame={func="callee4",args=[],
     file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="13"}
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="2",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
     addr="0x00010734",func="callee4",
     file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8",times="1"},
     bkpt={number="2",type="watchpoint",disp="keep",
     enabled="y",addr="",what="C",times="-5"}]}
     (gdb)
     -exec-continue
     ^running
     ^done,reason="watchpoint-scope",wpnum="2",
     frame={func="callee3",args=[{name="strarg",
     value="0x11940 \"A string argument.\""}],
     file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="18"}
     (gdb)
     -break-list
     ^done,BreakpointTable={nr_rows="1",nr_cols="6",
     hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},
     {width="14",alignment="-1",col_name="type",colhdr="Type"},
     {width="4",alignment="-1",col_name="disp",colhdr="Disp"},
     {width="3",alignment="-1",col_name="enabled",colhdr="Enb"},
     {width="10",alignment="-1",col_name="addr",colhdr="Address"},
     {width="40",alignment="2",col_name="what",colhdr="What"}],
     body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",
     addr="0x00010734",func="callee4",
     file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8",times="1"}]}
     (gdb)

Compare with Previous | Blame | View Log

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.