1299 lines
49 KiB
Plaintext
1299 lines
49 KiB
Plaintext
This is ./gdb.info, produced by Makeinfo version 3.12f 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 Eighth Edition, March 2000, of `Debugging with GDB: the
|
||
GNU Source-Level Debugger' for GDB Version 5.0.
|
||
|
||
Copyright (C) 1988-2000 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the entire resulting derived work is distributed under the terms
|
||
of a permission notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions.
|
||
|
||
|
||
File: gdb.info, Node: Expressions, Next: Variables, Up: Data
|
||
|
||
Expressions
|
||
===========
|
||
|
||
`print' and many other GDB commands accept an expression and compute
|
||
its value. Any kind of constant, variable or operator defined by the
|
||
programming language you are using is valid in an expression in GDB.
|
||
This includes conditional expressions, function calls, casts and string
|
||
constants. It unfortunately does not include symbols defined by
|
||
preprocessor `#define' commands.
|
||
|
||
GDB supports array constants in expressions input by the user. The
|
||
syntax is {ELEMENT, ELEMENT...}. For example, you can use the command
|
||
`print {1, 2, 3}' to build up an array in memory that is `malloc'ed in
|
||
the target program.
|
||
|
||
Because C is so widespread, most of the expressions shown in
|
||
examples in this manual are in C. *Note Using GDB with Different
|
||
Languages: Languages, for information on how to use expressions in other
|
||
languages.
|
||
|
||
In this section, we discuss operators that you can use in GDB
|
||
expressions regardless of your programming language.
|
||
|
||
Casts are supported in all languages, not just in C, because it is so
|
||
useful to cast a number into a pointer in order to examine a structure
|
||
at that address in memory.
|
||
|
||
GDB supports these operators, in addition to those common to
|
||
programming languages:
|
||
|
||
`@'
|
||
`@' is a binary operator for treating parts of memory as arrays.
|
||
*Note Artificial arrays: Arrays, for more information.
|
||
|
||
`::'
|
||
`::' allows you to specify a variable in terms of the file or
|
||
function where it is defined. *Note Program variables: Variables.
|
||
|
||
`{TYPE} ADDR'
|
||
Refers to an object of type TYPE stored at address ADDR in memory.
|
||
ADDR may be any expression whose value is an integer or pointer
|
||
(but parentheses are required around binary operators, just as in
|
||
a cast). This construct is allowed regardless of what kind of
|
||
data is normally supposed to reside at ADDR.
|
||
|
||
|
||
File: gdb.info, Node: Variables, Next: Arrays, Prev: Expressions, Up: Data
|
||
|
||
Program variables
|
||
=================
|
||
|
||
The most common kind of expression to use is the name of a variable
|
||
in your program.
|
||
|
||
Variables in expressions are understood in the selected stack frame
|
||
(*note Selecting a frame: Selection.); they must be either:
|
||
|
||
* global (or file-static)
|
||
|
||
or
|
||
|
||
* visible according to the scope rules of the programming language
|
||
from the point of execution in that frame
|
||
|
||
This means that in the function
|
||
|
||
foo (a)
|
||
int a;
|
||
{
|
||
bar (a);
|
||
{
|
||
int b = test ();
|
||
bar (b);
|
||
}
|
||
}
|
||
|
||
you can examine and use the variable `a' whenever your program is
|
||
executing within the function `foo', but you can only use or examine
|
||
the variable `b' while your program is executing inside the block where
|
||
`b' is declared.
|
||
|
||
There is an exception: you can refer to a variable or function whose
|
||
scope is a single source file even if the current execution point is not
|
||
in this file. But it is possible to have more than one such variable or
|
||
function with the same name (in different source files). If that
|
||
happens, referring to that name has unpredictable effects. If you wish,
|
||
you can specify a static variable in a particular function or file,
|
||
using the colon-colon notation:
|
||
|
||
FILE::VARIABLE
|
||
FUNCTION::VARIABLE
|
||
|
||
Here FILE or FUNCTION is the name of the context for the static
|
||
VARIABLE. In the case of file names, you can use quotes to make sure
|
||
GDB parses the file name as a single word--for example, to print a
|
||
global value of `x' defined in `f2.c':
|
||
|
||
(gdb) p 'f2.c'::x
|
||
|
||
This use of `::' is very rarely in conflict with the very similar
|
||
use of the same notation in C++. GDB also supports use of the C++
|
||
scope resolution operator in GDB expressions.
|
||
|
||
_Warning:_ Occasionally, a local variable may appear to have the
|
||
wrong value at certain points in a function--just after entry to a
|
||
new scope, and just before exit.
|
||
You may see this problem when you are stepping by machine
|
||
instructions. This is because, on most machines, it takes more than
|
||
one instruction to set up a stack frame (including local variable
|
||
definitions); if you are stepping by machine instructions, variables
|
||
may appear to have the wrong values until the stack frame is completely
|
||
built. On exit, it usually also takes more than one machine
|
||
instruction to destroy a stack frame; after you begin stepping through
|
||
that group of instructions, local variable definitions may be gone.
|
||
|
||
This may also happen when the compiler does significant
|
||
optimizations. To be sure of always seeing accurate values, turn off
|
||
all optimization when compiling.
|
||
|
||
Another possible effect of compiler optimizations is to optimize
|
||
unused variables out of existence, or assign variables to registers (as
|
||
opposed to memory addresses). Depending on the support for such cases
|
||
offered by the debug info format used by the compiler, GDB might not be
|
||
able to display values for such local variables. If that happens, GDB
|
||
will print a message like this:
|
||
|
||
No symbol "foo" in current context.
|
||
|
||
To solve such problems, either recompile without optimizations, or
|
||
use a different debug info format, if the compiler supports several such
|
||
formats. For example, GCC, the GNU C/C++ compiler usually supports the
|
||
`-gstabs' option. `-gstabs' produces debug info in a format that is
|
||
superior to formats such as COFF. You may be able to use DWARF-2
|
||
(`-gdwarf-2'), which is also an effective form for debug info. See
|
||
*Note Options for Debugging Your Program or GNU CC: (gcc.info)Debugging
|
||
Options, for more information.
|
||
|
||
|
||
File: gdb.info, Node: Arrays, Next: Output Formats, Prev: Variables, Up: Data
|
||
|
||
Artificial arrays
|
||
=================
|
||
|
||
It is often useful to print out several successive objects of the
|
||
same type in memory; a section of an array, or an array of dynamically
|
||
determined size for which only a pointer exists in the program.
|
||
|
||
You can do this by referring to a contiguous span of memory as an
|
||
"artificial array", using the binary operator `@'. The left operand of
|
||
`@' should be the first element of the desired array and be an
|
||
individual object. The right operand should be the desired length of
|
||
the array. The result is an array value whose elements are all of the
|
||
type of the left argument. The first element is actually the left
|
||
argument; the second element comes from bytes of memory immediately
|
||
following those that hold the first element, and so on. Here is an
|
||
example. If a program says
|
||
|
||
int *array = (int *) malloc (len * sizeof (int));
|
||
|
||
you can print the contents of `array' with
|
||
|
||
p *array@len
|
||
|
||
The left operand of `@' must reside in memory. Array values made
|
||
with `@' in this way behave just like other arrays in terms of
|
||
subscripting, and are coerced to pointers when used in expressions.
|
||
Artificial arrays most often appear in expressions via the value history
|
||
(*note Value history: Value History.), after printing one out.
|
||
|
||
Another way to create an artificial array is to use a cast. This
|
||
re-interprets a value as if it were an array. The value need not be in
|
||
memory:
|
||
(gdb) p/x (short[2])0x12345678
|
||
$1 = {0x1234, 0x5678}
|
||
|
||
As a convenience, if you leave the array length out (as in
|
||
`(TYPE[])VALUE') GDB calculates the size to fill the value (as
|
||
`sizeof(VALUE)/sizeof(TYPE)':
|
||
(gdb) p/x (short[])0x12345678
|
||
$2 = {0x1234, 0x5678}
|
||
|
||
Sometimes the artificial array mechanism is not quite enough; in
|
||
moderately complex data structures, the elements of interest may not
|
||
actually be adjacent--for example, if you are interested in the values
|
||
of pointers in an array. One useful work-around in this situation is
|
||
to use a convenience variable (*note Convenience variables: Convenience
|
||
Vars.) as a counter in an expression that prints the first interesting
|
||
value, and then repeat that expression via <RET>. For instance,
|
||
suppose you have an array `dtab' of pointers to structures, and you are
|
||
interested in the values of a field `fv' in each structure. Here is an
|
||
example of what you might type:
|
||
|
||
set $i = 0
|
||
p dtab[$i++]->fv
|
||
<RET>
|
||
<RET>
|
||
...
|
||
|
||
|
||
File: gdb.info, Node: Output Formats, Next: Memory, Prev: Arrays, Up: Data
|
||
|
||
Output formats
|
||
==============
|
||
|
||
By default, GDB prints a value according to its data type. Sometimes
|
||
this is not what you want. For example, you might want to print a
|
||
number in hex, or a pointer in decimal. Or you might want to view data
|
||
in memory at a certain address as a character string or as an
|
||
instruction. To do these things, specify an "output format" when you
|
||
print a value.
|
||
|
||
The simplest use of output formats is to say how to print a value
|
||
already computed. This is done by starting the arguments of the
|
||
`print' command with a slash and a format letter. The format letters
|
||
supported are:
|
||
|
||
`x'
|
||
Regard the bits of the value as an integer, and print the integer
|
||
in hexadecimal.
|
||
|
||
`d'
|
||
Print as integer in signed decimal.
|
||
|
||
`u'
|
||
Print as integer in unsigned decimal.
|
||
|
||
`o'
|
||
Print as integer in octal.
|
||
|
||
`t'
|
||
Print as integer in binary. The letter `t' stands for "two". (1)
|
||
|
||
`a'
|
||
Print as an address, both absolute in hexadecimal and as an offset
|
||
from the nearest preceding symbol. You can use this format used
|
||
to discover where (in what function) an unknown address is located:
|
||
|
||
(gdb) p/a 0x54320
|
||
$3 = 0x54320 <_initialize_vx+396>
|
||
|
||
`c'
|
||
Regard as an integer and print it as a character constant.
|
||
|
||
`f'
|
||
Regard the bits of the value as a floating point number and print
|
||
using typical floating point syntax.
|
||
|
||
For example, to print the program counter in hex (*note
|
||
Registers::.), type
|
||
|
||
p/x $pc
|
||
|
||
Note that no space is required before the slash; this is because command
|
||
names in GDB cannot contain a slash.
|
||
|
||
To reprint the last value in the value history with a different
|
||
format, you can use the `print' command with just a format and no
|
||
expression. For example, `p/x' reprints the last value in hex.
|
||
|
||
---------- Footnotes ----------
|
||
|
||
(1) `b' cannot be used because these format letters are also used
|
||
with the `x' command, where `b' stands for "byte"; see *Note Examining
|
||
memory: Memory.
|
||
|
||
|
||
File: gdb.info, Node: Memory, Next: Auto Display, Prev: Output Formats, Up: Data
|
||
|
||
Examining memory
|
||
================
|
||
|
||
You can use the command `x' (for "examine") to examine memory in any
|
||
of several formats, independently of your program's data types.
|
||
|
||
`x/NFU ADDR'
|
||
`x ADDR'
|
||
`x'
|
||
Use the `x' command to examine memory.
|
||
|
||
N, F, and U are all optional parameters that specify how much memory
|
||
to display and how to format it; ADDR is an expression giving the
|
||
address where you want to start displaying memory. If you use defaults
|
||
for NFU, you need not type the slash `/'. Several commands set
|
||
convenient defaults for ADDR.
|
||
|
||
N, the repeat count
|
||
The repeat count is a decimal integer; the default is 1. It
|
||
specifies how much memory (counting by units U) to display.
|
||
|
||
F, the display format
|
||
The display format is one of the formats used by `print', `s'
|
||
(null-terminated string), or `i' (machine instruction). The
|
||
default is `x' (hexadecimal) initially. The default changes each
|
||
time you use either `x' or `print'.
|
||
|
||
U, the unit size
|
||
The unit size is any of
|
||
|
||
`b'
|
||
Bytes.
|
||
|
||
`h'
|
||
Halfwords (two bytes).
|
||
|
||
`w'
|
||
Words (four bytes). This is the initial default.
|
||
|
||
`g'
|
||
Giant words (eight bytes).
|
||
|
||
Each time you specify a unit size with `x', that size becomes the
|
||
default unit the next time you use `x'. (For the `s' and `i'
|
||
formats, the unit size is ignored and is normally not written.)
|
||
|
||
ADDR, starting display address
|
||
ADDR is the address where you want GDB to begin displaying memory.
|
||
The expression need not have a pointer value (though it may); it
|
||
is always interpreted as an integer address of a byte of memory.
|
||
*Note Expressions: Expressions, for more information on
|
||
expressions. The default for ADDR is usually just after the last
|
||
address examined--but several other commands also set the default
|
||
address: `info breakpoints' (to the address of the last breakpoint
|
||
listed), `info line' (to the starting address of a line), and
|
||
`print' (if you use it to display a value from memory).
|
||
|
||
For example, `x/3uh 0x54320' is a request to display three halfwords
|
||
(`h') of memory, formatted as unsigned decimal integers (`u'), starting
|
||
at address `0x54320'. `x/4xw $sp' prints the four words (`w') of
|
||
memory above the stack pointer (here, `$sp'; *note Registers:
|
||
Registers.) in hexadecimal (`x').
|
||
|
||
Since the letters indicating unit sizes are all distinct from the
|
||
letters specifying output formats, you do not have to remember whether
|
||
unit size or format comes first; either order works. The output
|
||
specifications `4xw' and `4wx' mean exactly the same thing. (However,
|
||
the count N must come first; `wx4' does not work.)
|
||
|
||
Even though the unit size U is ignored for the formats `s' and `i',
|
||
you might still want to use a count N; for example, `3i' specifies that
|
||
you want to see three machine instructions, including any operands.
|
||
The command `disassemble' gives an alternative way of inspecting
|
||
machine instructions; see *Note Source and machine code: Machine Code.
|
||
|
||
All the defaults for the arguments to `x' are designed to make it
|
||
easy to continue scanning memory with minimal specifications each time
|
||
you use `x'. For example, after you have inspected three machine
|
||
instructions with `x/3i ADDR', you can inspect the next seven with just
|
||
`x/7'. If you use <RET> to repeat the `x' command, the repeat count N
|
||
is used again; the other arguments default as for successive uses of
|
||
`x'.
|
||
|
||
The addresses and contents printed by the `x' command are not saved
|
||
in the value history because there is often too much of them and they
|
||
would get in the way. Instead, GDB makes these values available for
|
||
subsequent use in expressions as values of the convenience variables
|
||
`$_' and `$__'. After an `x' command, the last address examined is
|
||
available for use in expressions in the convenience variable `$_'. The
|
||
contents of that address, as examined, are available in the convenience
|
||
variable `$__'.
|
||
|
||
If the `x' command has a repeat count, the address and contents saved
|
||
are from the last memory unit printed; this is not the same as the last
|
||
address printed if several units were printed on the last line of
|
||
output.
|
||
|
||
|
||
File: gdb.info, Node: Auto Display, Next: Print Settings, Prev: Memory, Up: Data
|
||
|
||
Automatic display
|
||
=================
|
||
|
||
If you find that you want to print the value of an expression
|
||
frequently (to see how it changes), you might want to add it to the
|
||
"automatic display list" so that GDB prints its value each time your
|
||
program stops. Each expression added to the list is given a number to
|
||
identify it; to remove an expression from the list, you specify that
|
||
number. The automatic display looks like this:
|
||
|
||
2: foo = 38
|
||
3: bar[5] = (struct hack *) 0x3804
|
||
|
||
This display shows item numbers, expressions and their current values.
|
||
As with displays you request manually using `x' or `print', you can
|
||
specify the output format you prefer; in fact, `display' decides
|
||
whether to use `print' or `x' depending on how elaborate your format
|
||
specification is--it uses `x' if you specify a unit size, or one of the
|
||
two formats (`i' and `s') that are only supported by `x'; otherwise it
|
||
uses `print'.
|
||
|
||
`display EXPR'
|
||
Add the expression EXPR to the list of expressions to display each
|
||
time your program stops. *Note Expressions: Expressions.
|
||
|
||
`display' does not repeat if you press <RET> again after using it.
|
||
|
||
`display/FMT EXPR'
|
||
For FMT specifying only a display format and not a size or count,
|
||
add the expression EXPR to the auto-display list but arrange to
|
||
display it each time in the specified format FMT. *Note Output
|
||
formats: Output Formats.
|
||
|
||
`display/FMT ADDR'
|
||
For FMT `i' or `s', or including a unit-size or a number of units,
|
||
add the expression ADDR as a memory address to be examined each
|
||
time your program stops. Examining means in effect doing `x/FMT
|
||
ADDR'. *Note Examining memory: Memory.
|
||
|
||
For example, `display/i $pc' can be helpful, to see the machine
|
||
instruction about to be executed each time execution stops (`$pc' is a
|
||
common name for the program counter; *note Registers: Registers.).
|
||
|
||
`undisplay DNUMS...'
|
||
`delete display DNUMS...'
|
||
Remove item numbers DNUMS from the list of expressions to display.
|
||
|
||
`undisplay' does not repeat if you press <RET> after using it.
|
||
(Otherwise you would just get the error `No display number ...'.)
|
||
|
||
`disable display DNUMS...'
|
||
Disable the display of item numbers DNUMS. A disabled display
|
||
item is not printed automatically, but is not forgotten. It may be
|
||
enabled again later.
|
||
|
||
`enable display DNUMS...'
|
||
Enable display of item numbers DNUMS. It becomes effective once
|
||
again in auto display of its expression, until you specify
|
||
otherwise.
|
||
|
||
`display'
|
||
Display the current values of the expressions on the list, just as
|
||
is done when your program stops.
|
||
|
||
`info display'
|
||
Print the list of expressions previously set up to display
|
||
automatically, each one with its item number, but without showing
|
||
the values. This includes disabled expressions, which are marked
|
||
as such. It also includes expressions which would not be
|
||
displayed right now because they refer to automatic variables not
|
||
currently available.
|
||
|
||
If a display expression refers to local variables, then it does not
|
||
make sense outside the lexical context for which it was set up. Such an
|
||
expression is disabled when execution enters a context where one of its
|
||
variables is not defined. For example, if you give the command
|
||
`display last_char' while inside a function with an argument
|
||
`last_char', GDB displays this argument while your program continues to
|
||
stop inside that function. When it stops elsewhere--where there is no
|
||
variable `last_char'--the display is disabled automatically. The next
|
||
time your program stops where `last_char' is meaningful, you can enable
|
||
the display expression once again.
|
||
|
||
|
||
File: gdb.info, Node: Print Settings, Next: Value History, Prev: Auto Display, Up: Data
|
||
|
||
Print settings
|
||
==============
|
||
|
||
GDB provides the following ways to control how arrays, structures,
|
||
and symbols are printed.
|
||
|
||
These settings are useful for debugging programs in any language:
|
||
|
||
`set print address'
|
||
`set print address on'
|
||
GDB prints memory addresses showing the location of stack traces,
|
||
structure values, pointer values, breakpoints, and so forth, even
|
||
when it also displays the contents of those addresses. The default
|
||
is `on'. For example, this is what a stack frame display looks
|
||
like with `set print address on':
|
||
|
||
(gdb) f
|
||
#0 set_quotes (lq=0x34c78 "<<", rq=0x34c88 ">>")
|
||
at input.c:530
|
||
530 if (lquote != def_lquote)
|
||
|
||
`set print address off'
|
||
Do not print addresses when displaying their contents. For
|
||
example, this is the same stack frame displayed with `set print
|
||
address off':
|
||
|
||
(gdb) set print addr off
|
||
(gdb) f
|
||
#0 set_quotes (lq="<<", rq=">>") at input.c:530
|
||
530 if (lquote != def_lquote)
|
||
|
||
You can use `set print address off' to eliminate all machine
|
||
dependent displays from the GDB interface. For example, with
|
||
`print address off', you should get the same text for backtraces on
|
||
all machines--whether or not they involve pointer arguments.
|
||
|
||
`show print address'
|
||
Show whether or not addresses are to be printed.
|
||
|
||
When GDB prints a symbolic address, it normally prints the closest
|
||
earlier symbol plus an offset. If that symbol does not uniquely
|
||
identify the address (for example, it is a name whose scope is a single
|
||
source file), you may need to clarify. One way to do this is with
|
||
`info line', for example `info line *0x4537'. Alternately, you can set
|
||
GDB to print the source file and line number when it prints a symbolic
|
||
address:
|
||
|
||
`set print symbol-filename on'
|
||
Tell GDB to print the source file name and line number of a symbol
|
||
in the symbolic form of an address.
|
||
|
||
`set print symbol-filename off'
|
||
Do not print source file name and line number of a symbol. This
|
||
is the default.
|
||
|
||
`show print symbol-filename'
|
||
Show whether or not GDB will print the source file name and line
|
||
number of a symbol in the symbolic form of an address.
|
||
|
||
Another situation where it is helpful to show symbol filenames and
|
||
line numbers is when disassembling code; GDB shows you the line number
|
||
and source file that corresponds to each instruction.
|
||
|
||
Also, you may wish to see the symbolic form only if the address being
|
||
printed is reasonably close to the closest earlier symbol:
|
||
|
||
`set print max-symbolic-offset MAX-OFFSET'
|
||
Tell GDB to only display the symbolic form of an address if the
|
||
offset between the closest earlier symbol and the address is less
|
||
than MAX-OFFSET. The default is 0, which tells GDB to always
|
||
print the symbolic form of an address if any symbol precedes it.
|
||
|
||
`show print max-symbolic-offset'
|
||
Ask how large the maximum offset is that GDB prints in a symbolic
|
||
address.
|
||
|
||
If you have a pointer and you are not sure where it points, try `set
|
||
print symbol-filename on'. Then you can determine the name and source
|
||
file location of the variable where it points, using `p/a POINTER'.
|
||
This interprets the address in symbolic form. For example, here GDB
|
||
shows that a variable `ptt' points at another variable `t', defined in
|
||
`hi2.c':
|
||
|
||
(gdb) set print symbol-filename on
|
||
(gdb) p/a ptt
|
||
$4 = 0xe008 <t in hi2.c>
|
||
|
||
_Warning:_ For pointers that point to a local variable, `p/a' does
|
||
not show the symbol name and filename of the referent, even with
|
||
the appropriate `set print' options turned on.
|
||
|
||
Other settings control how different kinds of objects are printed:
|
||
|
||
`set print array'
|
||
`set print array on'
|
||
Pretty print arrays. This format is more convenient to read, but
|
||
uses more space. The default is off.
|
||
|
||
`set print array off'
|
||
Return to compressed format for arrays.
|
||
|
||
`show print array'
|
||
Show whether compressed or pretty format is selected for displaying
|
||
arrays.
|
||
|
||
`set print elements NUMBER-OF-ELEMENTS'
|
||
Set a limit on how many elements of an array GDB will print. If
|
||
GDB is printing a large array, it stops printing after it has
|
||
printed the number of elements set by the `set print elements'
|
||
command. This limit also applies to the display of strings. When
|
||
GDB starts, this limit is set to 200. Setting NUMBER-OF-ELEMENTS
|
||
to zero means that the printing is unlimited.
|
||
|
||
`show print elements'
|
||
Display the number of elements of a large array that GDB will
|
||
print. If the number is 0, then the printing is unlimited.
|
||
|
||
`set print null-stop'
|
||
Cause GDB to stop printing the characters of an array when the
|
||
first NULL is encountered. This is useful when large arrays
|
||
actually contain only short strings. The default is off.
|
||
|
||
`set print pretty on'
|
||
Cause GDB to print structures in an indented format with one member
|
||
per line, like this:
|
||
|
||
$1 = {
|
||
next = 0x0,
|
||
flags = {
|
||
sweet = 1,
|
||
sour = 1
|
||
},
|
||
meat = 0x54 "Pork"
|
||
}
|
||
|
||
`set print pretty off'
|
||
Cause GDB to print structures in a compact format, like this:
|
||
|
||
$1 = {next = 0x0, flags = {sweet = 1, sour = 1}, \
|
||
meat = 0x54 "Pork"}
|
||
|
||
This is the default format.
|
||
|
||
`show print pretty'
|
||
Show which format GDB is using to print structures.
|
||
|
||
`set print sevenbit-strings on'
|
||
Print using only seven-bit characters; if this option is set, GDB
|
||
displays any eight-bit characters (in strings or character values)
|
||
using the notation `\'NNN. This setting is best if you are
|
||
working in English (ASCII) and you use the high-order bit of
|
||
characters as a marker or "meta" bit.
|
||
|
||
`set print sevenbit-strings off'
|
||
Print full eight-bit characters. This allows the use of more
|
||
international character sets, and is the default.
|
||
|
||
`show print sevenbit-strings'
|
||
Show whether or not GDB is printing only seven-bit characters.
|
||
|
||
`set print union on'
|
||
Tell GDB to print unions which are contained in structures. This
|
||
is the default setting.
|
||
|
||
`set print union off'
|
||
Tell GDB not to print unions which are contained in structures.
|
||
|
||
`show print union'
|
||
Ask GDB whether or not it will print unions which are contained in
|
||
structures.
|
||
|
||
For example, given the declarations
|
||
|
||
typedef enum {Tree, Bug} Species;
|
||
typedef enum {Big_tree, Acorn, Seedling} Tree_forms;
|
||
typedef enum {Caterpillar, Cocoon, Butterfly}
|
||
Bug_forms;
|
||
|
||
struct thing {
|
||
Species it;
|
||
union {
|
||
Tree_forms tree;
|
||
Bug_forms bug;
|
||
} form;
|
||
};
|
||
|
||
struct thing foo = {Tree, {Acorn}};
|
||
|
||
with `set print union on' in effect `p foo' would print
|
||
|
||
$1 = {it = Tree, form = {tree = Acorn, bug = Cocoon}}
|
||
|
||
and with `set print union off' in effect it would print
|
||
|
||
$1 = {it = Tree, form = {...}}
|
||
|
||
These settings are of interest when debugging C++ programs:
|
||
|
||
`set print demangle'
|
||
`set print demangle on'
|
||
Print C++ names in their source form rather than in the encoded
|
||
("mangled") form passed to the assembler and linker for type-safe
|
||
linkage. The default is on.
|
||
|
||
`show print demangle'
|
||
Show whether C++ names are printed in mangled or demangled form.
|
||
|
||
`set print asm-demangle'
|
||
`set print asm-demangle on'
|
||
Print C++ names in their source form rather than their mangled
|
||
form, even in assembler code printouts such as instruction
|
||
disassemblies. The default is off.
|
||
|
||
`show print asm-demangle'
|
||
Show whether C++ names in assembly listings are printed in mangled
|
||
or demangled form.
|
||
|
||
`set demangle-style STYLE'
|
||
Choose among several encoding schemes used by different compilers
|
||
to represent C++ names. The choices for STYLE are currently:
|
||
|
||
`auto'
|
||
Allow GDB to choose a decoding style by inspecting your
|
||
program.
|
||
|
||
`gnu'
|
||
Decode based on the GNU C++ compiler (`g++') encoding
|
||
algorithm. This is the default.
|
||
|
||
`hp'
|
||
Decode based on the HP ANSI C++ (`aCC') encoding algorithm.
|
||
|
||
`lucid'
|
||
Decode based on the Lucid C++ compiler (`lcc') encoding
|
||
algorithm.
|
||
|
||
`arm'
|
||
Decode using the algorithm in the `C++ Annotated Reference
|
||
Manual'. *Warning:* this setting alone is not sufficient to
|
||
allow debugging `cfront'-generated executables. GDB would
|
||
require further enhancement to permit that.
|
||
|
||
If you omit STYLE, you will see a list of possible formats.
|
||
|
||
`show demangle-style'
|
||
Display the encoding style currently in use for decoding C++
|
||
symbols.
|
||
|
||
`set print object'
|
||
`set print object on'
|
||
When displaying a pointer to an object, identify the _actual_
|
||
(derived) type of the object rather than the _declared_ type, using
|
||
the virtual function table.
|
||
|
||
`set print object off'
|
||
Display only the declared type of objects, without reference to the
|
||
virtual function table. This is the default setting.
|
||
|
||
`show print object'
|
||
Show whether actual, or declared, object types are displayed.
|
||
|
||
`set print static-members'
|
||
`set print static-members on'
|
||
Print static members when displaying a C++ object. The default is
|
||
on.
|
||
|
||
`set print static-members off'
|
||
Do not print static members when displaying a C++ object.
|
||
|
||
`show print static-members'
|
||
Show whether C++ static members are printed, or not.
|
||
|
||
`set print vtbl'
|
||
`set print vtbl on'
|
||
Pretty print C++ virtual function tables. The default is off.
|
||
(The `vtbl' commands do not work on programs compiled with the HP
|
||
ANSI C++ compiler (`aCC').)
|
||
|
||
`set print vtbl off'
|
||
Do not pretty print C++ virtual function tables.
|
||
|
||
`show print vtbl'
|
||
Show whether C++ virtual function tables are pretty printed, or
|
||
not.
|
||
|
||
|
||
File: gdb.info, Node: Value History, Next: Convenience Vars, Prev: Print Settings, Up: Data
|
||
|
||
Value history
|
||
=============
|
||
|
||
Values printed by the `print' command are saved in the GDB "value
|
||
history". This allows you to refer to them in other expressions.
|
||
Values are kept until the symbol table is re-read or discarded (for
|
||
example with the `file' or `symbol-file' commands). When the symbol
|
||
table changes, the value history is discarded, since the values may
|
||
contain pointers back to the types defined in the symbol table.
|
||
|
||
The values printed are given "history numbers" by which you can
|
||
refer to them. These are successive integers starting with one.
|
||
`print' shows you the history number assigned to a value by printing
|
||
`$NUM = ' before the value; here NUM is the history number.
|
||
|
||
To refer to any previous value, use `$' followed by the value's
|
||
history number. The way `print' labels its output is designed to
|
||
remind you of this. Just `$' refers to the most recent value in the
|
||
history, and `$$' refers to the value before that. `$$N' refers to the
|
||
Nth value from the end; `$$2' is the value just prior to `$$', `$$1' is
|
||
equivalent to `$$', and `$$0' is equivalent to `$'.
|
||
|
||
For example, suppose you have just printed a pointer to a structure
|
||
and want to see the contents of the structure. It suffices to type
|
||
|
||
p *$
|
||
|
||
If you have a chain of structures where the component `next' points
|
||
to the next one, you can print the contents of the next one with this:
|
||
|
||
p *$.next
|
||
|
||
You can print successive links in the chain by repeating this
|
||
command--which you can do by just typing <RET>.
|
||
|
||
Note that the history records values, not expressions. If the value
|
||
of `x' is 4 and you type these commands:
|
||
|
||
print x
|
||
set x=5
|
||
|
||
then the value recorded in the value history by the `print' command
|
||
remains 4 even though the value of `x' has changed.
|
||
|
||
`show values'
|
||
Print the last ten values in the value history, with their item
|
||
numbers. This is like `p $$9' repeated ten times, except that
|
||
`show values' does not change the history.
|
||
|
||
`show values N'
|
||
Print ten history values centered on history item number N.
|
||
|
||
`show values +'
|
||
Print ten history values just after the values last printed. If
|
||
no more values are available, `show values +' produces no display.
|
||
|
||
Pressing <RET> to repeat `show values N' has exactly the same effect
|
||
as `show values +'.
|
||
|
||
|
||
File: gdb.info, Node: Convenience Vars, Next: Registers, Prev: Value History, Up: Data
|
||
|
||
Convenience variables
|
||
=====================
|
||
|
||
GDB provides "convenience variables" that you can use within GDB to
|
||
hold on to a value and refer to it later. These variables exist
|
||
entirely within GDB; they are not part of your program, and setting a
|
||
convenience variable has no direct effect on further execution of your
|
||
program. That is why you can use them freely.
|
||
|
||
Convenience variables are prefixed with `$'. Any name preceded by
|
||
`$' can be used for a convenience variable, unless it is one of the
|
||
predefined machine-specific register names (*note Registers:
|
||
Registers.). (Value history references, in contrast, are _numbers_
|
||
preceded by `$'. *Note Value history: Value History.)
|
||
|
||
You can save a value in a convenience variable with an assignment
|
||
expression, just as you would set a variable in your program. For
|
||
example:
|
||
|
||
set $foo = *object_ptr
|
||
|
||
would save in `$foo' the value contained in the object pointed to by
|
||
`object_ptr'.
|
||
|
||
Using a convenience variable for the first time creates it, but its
|
||
value is `void' until you assign a new value. You can alter the value
|
||
with another assignment at any time.
|
||
|
||
Convenience variables have no fixed types. You can assign a
|
||
convenience variable any type of value, including structures and
|
||
arrays, even if that variable already has a value of a different type.
|
||
The convenience variable, when used as an expression, has the type of
|
||
its current value.
|
||
|
||
`show convenience'
|
||
Print a list of convenience variables used so far, and their
|
||
values. Abbreviated `show conv'.
|
||
|
||
One of the ways to use a convenience variable is as a counter to be
|
||
incremented or a pointer to be advanced. For example, to print a field
|
||
from successive elements of an array of structures:
|
||
|
||
set $i = 0
|
||
print bar[$i++]->contents
|
||
|
||
Repeat that command by typing <RET>.
|
||
|
||
Some convenience variables are created automatically by GDB and given
|
||
values likely to be useful.
|
||
|
||
`$_'
|
||
The variable `$_' is automatically set by the `x' command to the
|
||
last address examined (*note Examining memory: Memory.). Other
|
||
commands which provide a default address for `x' to examine also
|
||
set `$_' to that address; these commands include `info line' and
|
||
`info breakpoint'. The type of `$_' is `void *' except when set
|
||
by the `x' command, in which case it is a pointer to the type of
|
||
`$__'.
|
||
|
||
`$__'
|
||
The variable `$__' is automatically set by the `x' command to the
|
||
value found in the last address examined. Its type is chosen to
|
||
match the format in which the data was printed.
|
||
|
||
`$_exitcode'
|
||
The variable `$_exitcode' is automatically set to the exit code
|
||
when the program being debugged terminates.
|
||
|
||
On HP-UX systems, if you refer to a function or variable name that
|
||
begins with a dollar sign, GDB searches for a user or system name
|
||
first, before it searches for a convenience variable.
|
||
|
||
|
||
File: gdb.info, Node: Registers, Next: Floating Point Hardware, Prev: Convenience Vars, Up: Data
|
||
|
||
Registers
|
||
=========
|
||
|
||
You can refer to machine register contents, in expressions, as
|
||
variables with names starting with `$'. The names of registers are
|
||
different for each machine; use `info registers' to see the names used
|
||
on your machine.
|
||
|
||
`info registers'
|
||
Print the names and values of all registers except floating-point
|
||
registers (in the selected stack frame).
|
||
|
||
`info all-registers'
|
||
Print the names and values of all registers, including
|
||
floating-point registers.
|
||
|
||
`info registers REGNAME ...'
|
||
Print the "relativized" value of each specified register REGNAME.
|
||
As discussed in detail below, register values are normally
|
||
relative to the selected stack frame. REGNAME may be any register
|
||
name valid on the machine you are using, with or without the
|
||
initial `$'.
|
||
|
||
GDB has four "standard" register names that are available (in
|
||
expressions) on most machines--whenever they do not conflict with an
|
||
architecture's canonical mnemonics for registers. The register names
|
||
`$pc' and `$sp' are used for the program counter register and the stack
|
||
pointer. `$fp' is used for a register that contains a pointer to the
|
||
current stack frame, and `$ps' is used for a register that contains the
|
||
processor status. For example, you could print the program counter in
|
||
hex with
|
||
|
||
p/x $pc
|
||
|
||
or print the instruction to be executed next with
|
||
|
||
x/i $pc
|
||
|
||
or add four to the stack pointer(1) with
|
||
|
||
set $sp += 4
|
||
|
||
Whenever possible, these four standard register names are available
|
||
on your machine even though the machine has different canonical
|
||
mnemonics, so long as there is no conflict. The `info registers'
|
||
command shows the canonical names. For example, on the SPARC, `info
|
||
registers' displays the processor status register as `$psr' but you can
|
||
also refer to it as `$ps'; and on x86-based machines `$ps' is an alias
|
||
for the EFLAGS register.
|
||
|
||
GDB always considers the contents of an ordinary register as an
|
||
integer when the register is examined in this way. Some machines have
|
||
special registers which can hold nothing but floating point; these
|
||
registers are considered to have floating point values. There is no way
|
||
to refer to the contents of an ordinary register as floating point value
|
||
(although you can _print_ it as a floating point value with `print/f
|
||
$REGNAME').
|
||
|
||
Some registers have distinct "raw" and "virtual" data formats. This
|
||
means that the data format in which the register contents are saved by
|
||
the operating system is not the same one that your program normally
|
||
sees. For example, the registers of the 68881 floating point
|
||
coprocessor are always saved in "extended" (raw) format, but all C
|
||
programs expect to work with "double" (virtual) format. In such cases,
|
||
GDB normally works with the virtual format only (the format that makes
|
||
sense for your program), but the `info registers' command prints the
|
||
data in both formats.
|
||
|
||
Normally, register values are relative to the selected stack frame
|
||
(*note Selecting a frame: Selection.). This means that you get the
|
||
value that the register would contain if all stack frames farther in
|
||
were exited and their saved registers restored. In order to see the
|
||
true contents of hardware registers, you must select the innermost
|
||
frame (with `frame 0').
|
||
|
||
However, GDB must deduce where registers are saved, from the machine
|
||
code generated by your compiler. If some registers are not saved, or if
|
||
GDB is unable to locate the saved registers, the selected stack frame
|
||
makes no difference.
|
||
|
||
---------- Footnotes ----------
|
||
|
||
(1) This is a way of removing one word from the stack, on machines
|
||
where stacks grow downward in memory (most machines, nowadays). This
|
||
assumes that the innermost stack frame is selected; setting `$sp' is
|
||
not allowed when other stack frames are selected. To pop entire frames
|
||
off the stack, regardless of machine architecture, use `return'; see
|
||
*Note Returning from a function: Returning.
|
||
|
||
|
||
File: gdb.info, Node: Floating Point Hardware, Prev: Registers, Up: Data
|
||
|
||
Floating point hardware
|
||
=======================
|
||
|
||
Depending on the configuration, GDB may be able to give you more
|
||
information about the status of the floating point hardware.
|
||
|
||
`info float'
|
||
Display hardware-dependent information about the floating point
|
||
unit. The exact contents and layout vary depending on the
|
||
floating point chip. Currently, `info float' is supported on the
|
||
ARM and x86 machines.
|
||
|
||
|
||
File: gdb.info, Node: Languages, Next: Symbols, Prev: Data, 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.
|
||
|