Subversion Repositories or1k

This is ./gdb.info, produced by makeinfo version 4.0 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, April 2001, of `Debugging with GDB: the

GNU Source-Level Debugger' for GDB Version 20010707.

   Copyright (C)

1988,1989,1990,1991,1992,1993,1994,1995,1996,1998,1999,2000,2001

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 "A Sample GDB Session" and "Free Software",

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

Back-Cover Texts as in (a) below.

   (a) The FSF'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: Tracepoint Actions,  Next: Listing Tracepoints,  Prev: Tracepoint Passcounts,  Up: Set Tracepoints

Tracepoint Action Lists

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

`actions [NUM]'

     This command will prompt for a list of actions to be taken when the

     tracepoint is hit.  If the tracepoint number NUM is not specified,

     this command sets the actions for the one that was most recently

     defined (so that you can define a tracepoint and then say

     `actions' without bothering about its number).  You specify the

     actions themselves on the following lines, one action at a time,

     and terminate the actions list with a line containing just `end'.

     So far, the only defined actions are `collect' and

     `while-stepping'.

     To remove all actions from a tracepoint, type `actions NUM' and

     follow it immediately with `end'.

          (gdb) collect DATA // collect some data

          (gdb) while-stepping 5   // single-step 5 times and collect data

          (gdb) end                // signals the end of actions.

     In the following example, the action list begins with `collect'

     commands indicating the things to be collected when the tracepoint

     is hit.  Then, in order to single-step and collect additional data

     following the tracepoint, a `while-stepping' command is used,

     followed by the list of things to be collected while stepping.  The

     `while-stepping' command is terminated by its own separate `end'

     command.  Lastly, the action list is terminated by an `end'

     command.

          (gdb) trace foo

          (gdb) actions

          Enter actions for tracepoint 1, one per line:

          > collect bar,baz

          > collect $regs

          > while-stepping 12

            > collect $fp, $sp

            > end

          end

`collect EXPR1, EXPR2, ...'

     Collect values of the given expressions when the tracepoint is hit.

     This command accepts a comma-separated list of any valid

     expressions.  In addition to global, static, or local variables,

     the following special arguments are supported:

    `$regs'

          collect all registers

    `$args'

          collect all function arguments

    `$locals'

          collect all local variables.

     You can give several consecutive `collect' commands, each one with

     a single argument, or one `collect' command with several arguments

     separated by commas: the effect is the same.

     The command `info scope' (*note info scope: Symbols.) is

     particularly useful for figuring out what data to collect.

`while-stepping N'

     Perform N single-step traces after the tracepoint, collecting new

     data at each step.  The `while-stepping' command is followed by

     the list of what to collect while stepping (followed by its own

     `end' command):

          > while-stepping 12

            > collect $regs, myglobal

            > end

          >

     You may abbreviate `while-stepping' as `ws' or `stepping'.

File: gdb.info,  Node: Listing Tracepoints,  Next: Starting and Stopping Trace Experiment,  Prev: Tracepoint Actions,  Up: Set Tracepoints

Listing Tracepoints

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

`info tracepoints [NUM]'

     Display information the tracepoint NUM.  If you don't specify a

     tracepoint number displays information about all the tracepoints

     defined so far.  For each tracepoint, the following information is

     shown:

        * its number

        * whether it is enabled or disabled

        * its address

        * its passcount as given by the `passcount N' command

        * its step count as given by the `while-stepping N' command

        * where in the source files is the tracepoint set

        * its action list as given by the `actions' command

          (gdb) info trace

          Num Enb Address    PassC StepC What

          1   y   0x002117c4 0     0     

          2   y   0x0020dc64 0     0     in gdb_test at gdb_test.c:375

          3   y   0x0020b1f4 0     0     in collect_data at ../foo.c:1741

          (gdb)

     This command can be abbreviated `info tp'.

File: gdb.info,  Node: Starting and Stopping Trace Experiment,  Prev: Listing Tracepoints,  Up: Set Tracepoints

Starting and Stopping Trace Experiment

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

`tstart'

     This command takes no arguments.  It starts the trace experiment,

     and begins collecting data.  This has the side effect of

     discarding all the data collected in the trace buffer during the

     previous trace experiment.

`tstop'

     This command takes no arguments.  It ends the trace experiment, and

     stops collecting data.

     *Note:* a trace experiment and data collection may stop

     automatically if any tracepoint's passcount is reached (*note

     Tracepoint Passcounts::), or if the trace buffer becomes full.

`tstatus'

     This command displays the status of the current trace data

     collection.

   Here is an example of the commands we described so far:

     (gdb) trace gdb_c_test

     (gdb) actions

     Enter actions for tracepoint #1, one per line.

     > collect $regs,$locals,$args

     > while-stepping 11

       > collect $regs

       > end

     > end

     (gdb) tstart

        [time passes ...]

     (gdb) tstop

File: gdb.info,  Node: Analyze Collected Data,  Next: Tracepoint Variables,  Prev: Set Tracepoints,  Up: Tracepoints

Using the collected data

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

   After the tracepoint experiment ends, you use GDB commands for

examining the trace data.  The basic idea is that each tracepoint

collects a trace "snapshot" every time it is hit and another snapshot

every time it single-steps.  All these snapshots are consecutively

numbered from zero and go into a buffer, and you can examine them

later.  The way you examine them is to "focus" on a specific trace

snapshot.  When the remote stub is focused on a trace snapshot, it will

respond to all GDB requests for memory and registers by reading from

the buffer which belongs to that snapshot, rather than from _real_

memory or registers of the program being debugged.  This means that

*all* GDB commands (`print', `info registers', `backtrace', etc.) will

behave as if we were currently debugging the program state as it was

when the tracepoint occurred.  Any requests for data that are not in

the buffer will fail.

* Menu:

* tfind::                       How to select a trace snapshot

* tdump::                       How to display all data for a snapshot

* save-tracepoints::            How to save tracepoints for a future run

File: gdb.info,  Node: tfind,  Next: tdump,  Up: Analyze Collected Data

`tfind N'

---------

   The basic command for selecting a trace snapshot from the buffer is

`tfind N', which finds trace snapshot number N, counting from zero.  If

no argument N is given, the next snapshot is selected.

   Here are the various forms of using the `tfind' command.

`tfind start'

     Find the first snapshot in the buffer.  This is a synonym for

     `tfind 0' (since 0 is the number of the first snapshot).

`tfind none'

     Stop debugging trace snapshots, resume _live_ debugging.

`tfind end'

     Same as `tfind none'.

`tfind'

     No argument means find the next trace snapshot.

`tfind -'

     Find the previous trace snapshot before the current one.  This

     permits retracing earlier steps.

`tfind tracepoint NUM'

     Find the next snapshot associated with tracepoint NUM.  Search

     proceeds forward from the last examined trace snapshot.  If no

     argument NUM is given, it means find the next snapshot collected

     for the same tracepoint as the current snapshot.

`tfind pc ADDR'

     Find the next snapshot associated with the value ADDR of the

     program counter.  Search proceeds forward from the last examined

     trace snapshot.  If no argument ADDR is given, it means find the

     next snapshot with the same value of PC as the current snapshot.

`tfind outside ADDR1, ADDR2'

     Find the next snapshot whose PC is outside the given range of

     addresses.

`tfind range ADDR1, ADDR2'

     Find the next snapshot whose PC is between ADDR1 and ADDR2.

`tfind line [FILE:]N'

     Find the next snapshot associated with the source line N.  If the

     optional argument FILE is given, refer to line N in that source

     file.  Search proceeds forward from the last examined trace

     snapshot.  If no argument N is given, it means find the next line

     other than the one currently being examined; thus saying `tfind

     line' repeatedly can appear to have the same effect as stepping

     from line to line in a _live_ debugging session.

   The default arguments for the `tfind' commands are specifically

designed to make it easy to scan through the trace buffer.  For

instance, `tfind' with no argument selects the next trace snapshot, and

`tfind -' with no argument selects the previous trace snapshot.  So, by

giving one `tfind' command, and then simply hitting  repeatedly

you can examine all the trace snapshots in order.  Or, by saying `tfind

-' and then hitting  repeatedly you can examine the snapshots in

reverse order.  The `tfind line' command with no argument selects the

snapshot for the next source line executed.  The `tfind pc' command with

no argument selects the next snapshot with the same program counter

(PC) as the current frame.  The `tfind tracepoint' command with no

argument selects the next trace snapshot collected by the same

tracepoint as the current one.

   In addition to letting you scan through the trace buffer manually,

these commands make it easy to construct GDB scripts that scan through

the trace buffer and print out whatever collected data you are

interested in.  Thus, if we want to examine the PC, FP, and SP

registers from each trace frame in the buffer, we can say this:

     (gdb) tfind start

     (gdb) while ($trace_frame != -1)

     > printf "Frame %d, PC = %08X, SP = %08X, FP = %08X\n", \

               $trace_frame, $pc, $sp, $fp

     > tfind

     > end

     Frame 0, PC = 0020DC64, SP = 0030BF3C, FP = 0030BF44

     Frame 1, PC = 0020DC6C, SP = 0030BF38, FP = 0030BF44

     Frame 2, PC = 0020DC70, SP = 0030BF34, FP = 0030BF44

     Frame 3, PC = 0020DC74, SP = 0030BF30, FP = 0030BF44

     Frame 4, PC = 0020DC78, SP = 0030BF2C, FP = 0030BF44

     Frame 5, PC = 0020DC7C, SP = 0030BF28, FP = 0030BF44

     Frame 6, PC = 0020DC80, SP = 0030BF24, FP = 0030BF44

     Frame 7, PC = 0020DC84, SP = 0030BF20, FP = 0030BF44

     Frame 8, PC = 0020DC88, SP = 0030BF1C, FP = 0030BF44

     Frame 9, PC = 0020DC8E, SP = 0030BF18, FP = 0030BF44

     Frame 10, PC = 00203F6C, SP = 0030BE3C, FP = 0030BF14

   Or, if we want to examine the variable `X' at each source line in

the buffer:

     (gdb) tfind start

     (gdb) while ($trace_frame != -1)

     > printf "Frame %d, X == %d\n", $trace_frame, X

     > tfind line

     > end

     Frame 0, X = 1

     Frame 7, X = 2

     Frame 13, X = 255

File: gdb.info,  Node: tdump,  Next: save-tracepoints,  Prev: tfind,  Up: Analyze Collected Data

`tdump'

-------

   This command takes no arguments.  It prints all the data collected at

the current trace snapshot.

     (gdb) trace 444

     (gdb) actions

     Enter actions for tracepoint #2, one per line:

     > collect $regs, $locals, $args, gdb_long_test

     > end

     (gdb) tstart

     (gdb) tfind line 444

     #0  gdb_test (p1=0x11, p2=0x22, p3=0x33, p4=0x44, p5=0x55, p6=0x66)

     at gdb_test.c:444

     444        printp( "%s: arguments = 0x%X 0x%X 0x%X 0x%X 0x%X 0x%X\n", )

     (gdb) tdump

     Data collected at tracepoint 2, trace frame 1:

     d0             0xc4aa0085       -995491707

     d1             0x18     24

     d2             0x80     128

     d3             0x33     51

     d4             0x71aea3d        119204413

     d5             0x22     34

     d6             0xe0     224

     d7             0x380035 3670069

     a0             0x19e24a 1696330

     a1             0x3000668        50333288

     a2             0x100    256

     a3             0x322000 3284992

     a4             0x3000698        50333336

     a5             0x1ad3cc 1758156

     fp             0x30bf3c 0x30bf3c

     sp             0x30bf34 0x30bf34

     ps             0x0      0

     pc             0x20b2c8 0x20b2c8

     fpcontrol      0x0      0

     fpstatus       0x0      0

     fpiaddr        0x0      0

     p = 0x20e5b4 "gdb-test"

     p1 = (void *) 0x11

     p2 = (void *) 0x22

     p3 = (void *) 0x33

     p4 = (void *) 0x44

     p5 = (void *) 0x55

     p6 = (void *) 0x66

     gdb_long_test = 17 '\021'

     (gdb)

File: gdb.info,  Node: save-tracepoints,  Prev: tdump,  Up: Analyze Collected Data

`save-tracepoints FILENAME'

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

   This command saves all current tracepoint definitions together with

their actions and passcounts, into a file `FILENAME' suitable for use

in a later debugging session.  To read the saved tracepoint

definitions, use the `source' command (*note Command Files::).

File: gdb.info,  Node: Tracepoint Variables,  Prev: Analyze Collected Data,  Up: Tracepoints

Convenience Variables for Tracepoints

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

`(int) $trace_frame'

     The current trace snapshot (a.k.a. "frame") number, or -1 if no

     snapshot is selected.

`(int) $tracepoint'

     The tracepoint for the current trace snapshot.

`(int) $trace_line'

     The line number for the current trace snapshot.

`(char []) $trace_file'

     The source file for the current trace snapshot.

`(char []) $trace_func'

     The name of the function containing `$tracepoint'.

   Note: `$trace_file' is not suitable for use in `printf', use

`output' instead.

   Here's a simple example of using these convenience variables for

stepping through all the trace snapshots and printing some of their

data.

     (gdb) tfind start

     (gdb) while $trace_frame != -1

     > output $trace_file

     > printf ", line %d (tracepoint #%d)\n", $trace_line, $tracepoint

     > tfind

     > end

File: gdb.info,  Node: Languages,  Next: Symbols,  Prev: Tracepoints,  Up: Top

Using GDB with Different Languages

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

   Although programming languages generally have common aspects, they

are rarely expressed in the same manner.  For instance, in ANSI C,

dereferencing a pointer `p' is accomplished by `*p', but in Modula-2,

it is accomplished by `p^'.  Values can also be represented (and

displayed) differently.  Hex numbers in C appear as `0x1ae', while in

Modula-2 they appear as `1AEH'.

   Language-specific information is built into GDB for some languages,

allowing you to express operations like the above in your program's

native language, and allowing GDB to output values in a manner

consistent with the syntax of your program's native language.  The

language you use to build expressions is called the "working language".

* Menu:

* Setting::                     Switching between source languages

* Show::                        Displaying the language

* Checks::                      Type and range checks

* Support::                     Supported languages

File: gdb.info,  Node: Setting,  Next: Show,  Up: Languages

Switching between source languages

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

   There are two ways to control the working language--either have GDB

set it automatically, or select it manually yourself.  You can use the

`set language' command for either purpose.  On startup, GDB defaults to

setting the language automatically.  The working language is used to

determine how expressions you type are interpreted, how values are

printed, etc.

   In addition to the working language, every source file that GDB

knows about has its own working language.  For some object file

formats, the compiler might indicate which language a particular source

file is in.  However, most of the time GDB infers the language from the

name of the file.  The language of a source file controls whether C++

names are demangled--this way `backtrace' can show each frame

appropriately for its own language.  There is no way to set the

language of a source file from within GDB, but you can set the language

associated with a filename extension.  *Note Displaying the language:

Show.

   This is most commonly a problem when you use a program, such as

`cfront' or `f2c', that generates C but is written in another language.

In that case, make the program use `#line' directives in its C output;

that way GDB will know the correct language of the source code of the

original program, and will display that source code, not the generated

C code.

* Menu:

* Filenames::                   Filename extensions and languages.

* Manually::                    Setting the working language manually

* Automatically::               Having GDB infer the source language

File: gdb.info,  Node: Filenames,  Next: Manually,  Up: Setting

List of filename extensions and languages

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

   If a source file name ends in one of the following extensions, then

GDB infers that its language is the one indicated.

`.c'

     C source file

`.C'

`.cc'

`.cp'

`.cpp'

`.cxx'

`.c++'

     C++ source file

`.f'

`.F'

     Fortran source file

`.ch'

`.c186'

`.c286'

     CHILL source file

`.mod'

     Modula-2 source file

`.s'

`.S'

     Assembler source file.  This actually behaves almost like C, but

     GDB does not skip over function prologues when stepping.

   In addition, you may set the language associated with a filename

extension.  *Note Displaying the language: Show.

File: gdb.info,  Node: Manually,  Next: Automatically,  Prev: Filenames,  Up: Setting

Setting the working language

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

   If you allow GDB to set the language automatically, expressions are

interpreted the same way in your debugging session and your program.

   If you wish, you may set the language manually.  To do this, issue

the command `set language LANG', where LANG is the name of a language,

such as `c' or `modula-2'.  For a list of the supported languages, type

`set language'.

   Setting the language manually prevents GDB from updating the working

language automatically.  This can lead to confusion if you try to debug

a program when the working language is not the same as the source

language, when an expression is acceptable to both languages--but means

different things.  For instance, if the current source file were

written in C, and GDB was parsing Modula-2, a command such as:

     print a = b + c

might not have the effect you intended.  In C, this means to add `b'

and `c' and place the result in `a'.  The result printed would be the

value of `a'.  In Modula-2, this means to compare `a' to the result of

`b+c', yielding a `BOOLEAN' value.

File: gdb.info,  Node: Automatically,  Prev: Manually,  Up: Setting

Having GDB infer the source language

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

   To have GDB set the working language automatically, use `set

language local' or `set language auto'.  GDB then infers the working

language.  That is, when your program stops in a frame (usually by

encountering a breakpoint), GDB sets the working language to the

language recorded for the function in that frame.  If the language for

a frame is unknown (that is, if the function or block corresponding to

the frame was defined in a source file that does not have a recognized

extension), the current working language is not changed, and GDB issues

a warning.

   This may not seem necessary for most programs, which are written

entirely in one source language.  However, program modules and libraries

written in one source language can be used by a main program written in

a different source language.  Using `set language auto' in this case

frees you from having to set the working language manually.

File: gdb.info,  Node: Show,  Next: Checks,  Prev: Setting,  Up: Languages

Displaying the language

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

   The following commands help you find out which language is the

working language, and also what language source files were written in.

`show language'

     Display the current working language.  This is the language you

     can use with commands such as `print' to build and compute

     expressions that may involve variables in your program.

`info frame'

     Display the source language for this frame.  This language becomes

     the working language if you use an identifier from this frame.

     *Note Information about a frame: Frame Info, to identify the other

     information listed here.

`info source'

     Display the source language of this source file.  *Note Examining

     the Symbol Table: Symbols, to identify the other information

     listed here.

   In unusual circumstances, you may have source files with extensions

not in the standard list.  You can then set the extension associated

with a language explicitly:

`set extension-language .EXT LANGUAGE'

     Set source files with extension .EXT to be assumed to be in the

     source language LANGUAGE.

`info extensions'

     List all the filename extensions and the associated languages.

File: gdb.info,  Node: Checks,  Next: Support,  Prev: Show,  Up: Languages

Type and range checking

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

     _Warning:_ In this release, the GDB commands for type and range

     checking are included, but they do not yet have any effect.  This

     section documents the intended facilities.

   Some languages are designed to guard you against making seemingly

common errors through a series of compile- and run-time checks.  These

include checking the type of arguments to functions and operators, and

making sure mathematical overflows are caught at run time.  Checks such

as these help to ensure a program's correctness once it has been

compiled by eliminating type mismatches, and providing active checks

for range errors when your program is running.

   GDB can check for conditions like the above if you wish.  Although

GDB does not check the statements in your program, it can check

expressions entered directly into GDB for evaluation via the `print'

command, for example.  As with the working language, GDB can also

decide whether or not to check automatically based on your program's

source language.  *Note Supported languages: Support, for the default

settings of supported languages.

* Menu:

* Type Checking::               An overview of type checking

* Range Checking::              An overview of range checking

File: gdb.info,  Node: Type Checking,  Next: Range Checking,  Up: Checks

An overview of type checking

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

   Some languages, such as Modula-2, are strongly typed, meaning that

the arguments to operators and functions have to be of the correct type,

otherwise an error occurs.  These checks prevent type mismatch errors

from ever causing any run-time problems.  For example,

     1 + 2 => 3

but

     error--> 1 + 2.3

   The second example fails because the `CARDINAL' 1 is not

type-compatible with the `REAL' 2.3.

   For the expressions you use in GDB commands, you can tell the GDB

type checker to skip checking; to treat any mismatches as errors and

abandon the expression; or to only issue warnings when type mismatches

occur, but evaluate the expression anyway.  When you choose the last of

these, GDB evaluates expressions like the second example above, but

also issues a warning.

   Even if you turn type checking off, there may be other reasons

related to type that prevent GDB from evaluating an expression.  For

instance, GDB does not know how to add an `int' and a `struct foo'.

These particular type errors have nothing to do with the language in

use, and usually arise from expressions, such as the one described

above, which make little sense to evaluate anyway.

   Each language defines to what degree it is strict about type.  For

instance, both Modula-2 and C require the arguments to arithmetical

operators to be numbers.  In C, enumerated types and pointers can be

represented as numbers, so that they are valid arguments to mathematical

operators.  *Note Supported languages: Support, for further details on

specific languages.

   GDB provides some additional commands for controlling the type

checker:

`set check type auto'

     Set type checking on or off based on the current working language.

     *Note Supported languages: Support, for the default settings for

     each language.

`set check type on'

`set check type off'

     Set type checking on or off, overriding the default setting for the

     current working language.  Issue a warning if the setting does not

     match the language default.  If any type mismatches occur in

     evaluating an expression while type checking is on, GDB prints a

     message and aborts evaluation of the expression.

`set check type warn'

     Cause the type checker to issue warnings, but to always attempt to

     evaluate the expression.  Evaluating the expression may still be

     impossible for other reasons.  For example, GDB cannot add numbers

     and structures.

`show type'

     Show the current setting of the type checker, and whether or not

     GDB is setting it automatically.

File: gdb.info,  Node: Range Checking,  Prev: Type Checking,  Up: Checks

An overview of range checking

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

   In some languages (such as Modula-2), it is an error to exceed the

bounds of a type; this is enforced with run-time checks.  Such range

checking is meant to ensure program correctness by making sure

computations do not overflow, or indices on an array element access do

not exceed the bounds of the array.

   For expressions you use in GDB commands, you can tell GDB to treat

range errors in one of three ways: ignore them, always treat them as

errors and abandon the expression, or issue warnings but evaluate the

expression anyway.

   A range error can result from numerical overflow, from exceeding an

array index bound, or when you type a constant that is not a member of

any type.  Some languages, however, do not treat overflows as an error.

In many implementations of C, mathematical overflow causes the result

to "wrap around" to lower values--for example, if M is the largest

integer value, and S is the smallest, then

     M + 1 => S

   This, too, is specific to individual languages, and in some cases

specific to individual compilers or machines.  *Note Supported

languages: Support, for further details on specific languages.

   GDB provides some additional commands for controlling the range

checker:

`set check range auto'

     Set range checking on or off based on the current working language.

     *Note Supported languages: Support, for the default settings for

     each language.

`set check range on'

`set check range off'

     Set range checking on or off, overriding the default setting for

     the current working language.  A warning is issued if the setting

     does not match the language default.  If a range error occurs and

     range checking is on, then a message is printed and evaluation of

     the expression is aborted.

`set check range warn'

     Output messages when the GDB range checker detects a range error,

     but attempt to evaluate the expression anyway.  Evaluating the

     expression may still be impossible for other reasons, such as

     accessing memory that the process does not own (a typical example

     from many Unix systems).

`show range'

     Show the current setting of the range checker, and whether or not

     it is being set automatically by GDB.

File: gdb.info,  Node: Support,  Prev: Checks,  Up: Languages

Supported languages

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

   GDB supports C, C++, Fortran, Java, Chill, assembly, and Modula-2.

Some GDB features may be used in expressions regardless of the language

you use: the GDB `@' and `::' operators, and the `{type}addr' construct

(*note Expressions: Expressions.) can be used with the constructs of

any supported language.

   The following sections detail to what degree each source language is

supported by GDB.  These sections are not meant to be language

tutorials or references, but serve only as a reference guide to what the

GDB expression parser accepts, and what input and output formats should

look like for different languages.  There are many good books written

on each of these languages; please look to these for a language

reference or tutorial.

* Menu:

* C::           C and C++

* Modula-2::    Modula-2

* Chill::        Chill

File: gdb.info,  Node: C,  Next: Modula-2,  Up: Support

C and C++

---------

   Since C and C++ are so closely related, many features of GDB apply

to both languages.  Whenever this is the case, we discuss those

languages together.

   The C++ debugging facilities are jointly implemented by the C++

compiler and GDB.  Therefore, to debug your C++ code effectively, you

must compile your C++ programs with a supported C++ compiler, such as

GNU `g++', or the HP ANSI C++ compiler (`aCC').

   For best results when using GNU C++, use the stabs debugging format.

You can select that format explicitly with the `g++' command-line

options `-gstabs' or `-gstabs+'.  See *Note Options for Debugging Your

Program or GNU CC: (gcc.info)Debugging Options, for more information.

* Menu:

* C Operators::                 C and C++ operators

* C Constants::                 C and C++ constants

* C plus plus expressions::     C++ expressions

* C Defaults::                  Default settings for C and C++

* C Checks::                    C and C++ type and range checks

* Debugging C::                 GDB and C

* Debugging C plus plus::       GDB features for C++

File: gdb.info,  Node: C Operators,  Next: C Constants,  Up: C

C and C++ operators

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

   Operators must be defined on values of specific types.  For instance,

`+' is defined on numbers, but not on structures.  Operators are often

defined on groups of types.

   For the purposes of C and C++, the following definitions hold:

   * _Integral types_ include `int' with any of its storage-class

     specifiers; `char'; `enum'; and, for C++, `bool'.

   * _Floating-point types_ include `float', `double', and `long

     double' (if supported by the target platform).

   * _Pointer types_ include all types defined as `(TYPE *)'.

   * _Scalar types_ include all of the above.

The following operators are supported.  They are listed here in order

of increasing precedence:

`,'

     The comma or sequencing operator.  Expressions in a

     comma-separated list are evaluated from left to right, with the

     result of the entire expression being the last expression

     evaluated.

`='

     Assignment.  The value of an assignment expression is the value

     assigned.  Defined on scalar types.

`OP='

     Used in an expression of the form `A OP= B', and translated to

     `A = A OP B'.  `OP=' and `=' have the same precedence.  OP is any

     one of the operators `|', `^', `&', `<<', `>>', `+', `-', `*',

     `/', `%'.

`?:'

     The ternary operator.  `A ? B : C' can be thought of as:  if A

     then B else C.  A should be of an integral type.

`||'

     Logical OR.  Defined on integral types.

`&&'

     Logical AND.  Defined on integral types.

`|'

     Bitwise OR.  Defined on integral types.

`^'

     Bitwise exclusive-OR.  Defined on integral types.

`&'

     Bitwise AND.  Defined on integral types.

`==, !='

     Equality and inequality.  Defined on scalar types.  The value of

     these expressions is 0 for false and non-zero for true.

`<, >, <=, >='

     Less than, greater than, less than or equal, greater than or equal.

     Defined on scalar types.  The value of these expressions is 0 for

     false and non-zero for true.

`<<, >>'

     left shift, and right shift.  Defined on integral types.

`@'

     The GDB "artificial array" operator (*note Expressions:

     Expressions.).

`+, -'

     Addition and subtraction.  Defined on integral types,

     floating-point types and pointer types.

`*, /, %'

     Multiplication, division, and modulus.  Multiplication and

     division are defined on integral and floating-point types.

     Modulus is defined on integral types.

`++, --'

     Increment and decrement.  When appearing before a variable, the

     operation is performed before the variable is used in an

     expression; when appearing after it, the variable's value is used

     before the operation takes place.

`*'

     Pointer dereferencing.  Defined on pointer types.  Same precedence

     as `++'.

`&'

     Address operator.  Defined on variables.  Same precedence as `++'.

     For debugging C++, GDB implements a use of `&' beyond what is

     allowed in the C++ language itself: you can use `&(&REF)' (or, if

     you prefer, simply `&&REF') to examine the address where a C++

     reference variable (declared with `&REF') is stored.

`-'

     Negative.  Defined on integral and floating-point types.  Same

     precedence as `++'.

`!'

     Logical negation.  Defined on integral types.  Same precedence as

     `++'.

`~'

     Bitwise complement operator.  Defined on integral types.  Same

     precedence as `++'.

`., ->'

     Structure member, and pointer-to-structure member.  For

     convenience, GDB regards the two as equivalent, choosing whether

     to dereference a pointer based on the stored type information.

     Defined on `struct' and `union' data.