| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The usual way to examine data in your program is with the print
command (abbreviated p), or its synonym inspect. It
evaluates and prints the value of an expression of the language your
program is written in (see section Using GDB with Different Languages).
print expr
print /f expr
print
print /f
A more low-level way of examining data is with the x command.
It examines data in memory at a specified address and prints it in a
specified format. See section Examining memory.
If you are interested in information about types, or about how the
fields of a struct or a class are declared, use the ptype exp
command rather than print. See section Examining the Symbol Table.
8.1 Expressions 8.2 Program variables 8.3 Artificial arrays 8.4 Output formats 8.5 Examining memory 8.6 Automatic display 8.7 Print settings 8.8 Value history 8.9 Convenience variables 8.10 Registers 8.11 Floating point hardware 8.12 Vector Unit 8.13 Operating system auxiliary vector Auxiliary data provided by operating system 8.14 Memory region attributes 8.15 Copy between memory and a file 8.16 Character Sets Debugging programs that use a different character set than GDB does
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 also includes preprocessor macros, if
you compiled your program to include this information; see
4.1 Compiling for debugging.
Beware that nested functions usually need a context to be set up before being called. Unfortunately, GDB currently has no knowledge of this setup, and hence generally cannot call nested functions correctly. Therefore, the result of such a call is likely to be erroneous, and even to crash the program being debugged.
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 malloced in the target program.
Because C is so widespread, most of the expressions shown in examples in this manual are in C. See section Using GDB with Different 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:
@
::
{type} addr
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 (see section Selecting a frame); they must be either:
or
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 section `Options for Debugging Your Program or GNU CC' in Using GNU CC. See section Debugging C++, for more info about debug info formats that are best suited to C++ programs.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 (see section 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 (see section Convenience variables) 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 ... |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
d
u
o
t
a
(gdb) p/a 0x54320 $3 = 0x54320 <_initialize_vx+396> |
The command info symbol 0x54320 yields similar results.
See section info symbol.
c
f
For example, to print the program counter in hex (see section 8.10 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
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.
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.
b
h
w
g
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.)
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';
see section 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 Source and 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
display does not repeat if you press RET again after using it.
display/fmt expr
display/fmt addr
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; see section Registers).
undisplay dnums...
delete display dnums...
undisplay does not repeat if you press RET after using it.
(Otherwise you would just get the error `No display number ...'.)
disable display dnums...
enable display dnums...
display
info display
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
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
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
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
set print symbol-filename off
show print symbol-filename
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
show print max-symbolic-offset
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
set print array off
show print array
set print elements number-of-elements
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
set print null-stop
set print pretty on
$1 = {
next = 0x0,
flags = {
sweet = 1,
sour = 1
},
meat = 0x54 "Pork"
}
|
set print pretty off
$1 = {next = 0x0, flags = {sweet = 1, sour = 1}, \
meat = 0x54 "Pork"}
|
This is the default format.
show print pretty
set print sevenbit-strings on
\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
show print sevenbit-strings
set print union on
set print union off
show print union
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
show print demangle
set print asm-demangle
set print asm-demangle on
show print asm-demangle
set demangle-style style
auto
gnu
g++) encoding algorithm.
This is the default.
hp
aCC) encoding algorithm.
lucid
lcc) encoding algorithm.
arm
cfront-generated executables. GDB would
require further enhancement to permit that.
show demangle-style
set print object
set print object on
set print object off
show print object
set print static-members
set print static-members on
set print static-members off
show print static-members
set print vtbl
set print vtbl on
vtbl commands do not work on programs compiled with the HP
ANSI C++ compiler (aCC).)
set print vtbl off
show print vtbl
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
show
values does not change the history.
show values n
show values +
show values + produces no display.
Pressing RET to repeat show values n has exactly the
same effect as `show values +'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 (see section Registers). (Value history references, in contrast, are numbers preceded by `$'. See section 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
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.
$_
$_ is automatically set by the x command to
the last address examined (see section Examining 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 $__.
$__
$__ 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
$_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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
info all-registers
info registers regname ...
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(3) 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 (see section Selecting a frame). 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Depending on the configuration, GDB may be able to give you more information about the status of the floating point hardware.
info float
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Depending on the configuration, GDB may be able to give you more information about the status of the vector unit.
info vector
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some operating systems supply an auxiliary vector to programs at startup. This is akin to the arguments and environment that you specify for a program, but contains a system-dependent variety of binary values that tell system libraries important details about the hardware, operating system, and process. Each value's purpose is identified by an integer tag; the meanings are well-known but system-specific. Depending on the configuration and operating system facilities, GDB may be able to show you this information.
info auxv
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Memory region attributes allow you to describe special handling required by regions of your target's memory. GDB uses attributes to determine whether to allow certain types of memory accesses; whether to use specific width accesses; and whether to cache target memory.
Defined memory regions can be individually enabled and disabled. When a memory region is disabled, GDB uses the default attributes when accessing memory in that region. Similarly, if no memory regions have been defined, GDB uses the default attributes when accessing all memory.
When a memory region is defined, it is given a number to identify it; to enable, disable, or remove a memory region, you specify that number.
mem lower upper attributes...
delete mem nums...
disable mem nums...
enable mem nums...
info mem
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
While these attributes prevent GDB from performing invalid memory accesses, they do nothing to prevent the target system, I/O DMA, etc. from accessing memory.
ro
wo
rw
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
8
16
32
64
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
cache
nocache
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can use the commands dump, append, and
restore to copy data between target memory and a file. The
dump and append commands write data to a file, and the
restore command reads data from a file back into the inferior's
memory. Files may be in binary, Motorola S-record, Intel hex, or
Tektronix Hex format; however, GDB can only append to binary
files.
dump [format] memory filename start_addr end_addr
dump [format] value filename expr
The format parameter may be any one of:
binary
ihex
srec
tekhex
GDB uses the same definitions of these formats as the GNU binary utilities, like `objdump' and `objcopy'. If format is omitted, GDB dumps the data in raw binary form.
append [binary] memory filename start_addr end_addr
append [binary] value filename expr
restore filename [binary] bias start end
restore command can automatically recognize any known BFD
file format, except for raw binary. To restore a raw binary file you
must specify the optional keyword binary after the filename.
If bias is non-zero, its value will be added to the addresses contained in the file. Binary files always start at address zero, so they will be restored at address bias. Other bfd files have a built-in location; they will be restored at offset bias from that location.
If start and/or end are non-zero, then only data between file offset start and file offset end will be restored. These offsets are relative to the addresses in the file, before the bias argument is applied.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If the program you are debugging uses a different character set to represent characters and strings than the one GDB uses itself, GDB can automatically translate between the character sets for you. The character set GDB uses we call the host character set; the one the inferior program uses we call the target character set.
For example, if you are running GDB on a GNU/Linux system, which
uses the ISO Latin 1 character set, but you are using GDB's
remote protocol (see section Remote Debugging) to debug a program
running on an IBM mainframe, which uses the EBCDIC character set,
then the host character set is Latin-1, and the target character set is
EBCDIC. If you give GDB the command set
target-charset EBCDIC-US, then GDB translates between
EBCDIC and Latin 1 as you print character or string values, or use
character and string literals in expressions.
GDB has no way to automatically recognize which character set
the inferior program uses; you must tell it, using the set
target-charset command, described below.
Here are the commands for controlling GDB's character set support:
set target-charset charset
set target-charset followed by TABTAB, GDB will
list the target character sets it supports.
set host-charset charset
By default, GDB uses a host character set appropriate to the
system it is running on; you can override that default using the
set host-charset command.
GDB can only use certain character sets as its host character
set. We list the character set names GDB recognizes below, and
indicate which can be host character sets, but if you type
set target-charset followed by TABTAB, GDB will
list the host character sets it supports.
set charset charset
set charset followed by TABTAB,
GDB will list the name of the character sets that can be used
for both host and target.
show charset
show host-charset
show target-charset
GDB currently includes support for the following character sets:
ASCII
ISO-8859-1
EBCDIC-US
IBM1047
Note that these are all single-byte character sets. More work inside GDB is needed to support multi-byte or variable-width character encodings, like the UTF-8 and UCS-2 encodings of Unicode.
Here is an example of GDB's character set support in action. Assume that the following source code has been placed in the file `charset-test.c':
#include <stdio.h>
char ascii_hello[]
= {72, 101, 108, 108, 111, 44, 32, 119,
111, 114, 108, 100, 33, 10, 0};
char ibm1047_hello[]
= {200, 133, 147, 147, 150, 107, 64, 166,
150, 153, 147, 132, 90, 37, 0};
main ()
{
printf ("Hello, world!\n");
}
|
In this program, ascii_hello and ibm1047_hello are arrays
containing the string `Hello, world!' followed by a newline,
encoded in the ASCII and IBM1047 character sets.
We compile the program, and invoke the debugger on it:
$ gcc -g charset-test.c -o charset-test $ gdb -nw charset-test GNU gdb 2001-12-19-cvs Copyright 2001 Free Software Foundation, Inc. ... (gdb) |
We can use the show charset command to see what character sets
GDB is currently using to interpret and display characters and
strings:
(gdb) show charset The current host and target character set is `ISO-8859-1'. (gdb) |
For the sake of printing this manual, let's use ASCII as our initial character set:
(gdb) set charset ASCII (gdb) show charset The current host and target character set is `ASCII'. (gdb) |
Let's assume that ASCII is indeed the correct character set for our
host system -- in other words, let's assume that if GDB prints
characters using the ASCII character set, our terminal will display
them properly. Since our current target character set is also
ASCII, the contents of ascii_hello print legibly:
(gdb) print ascii_hello $1 = 0x401698 "Hello, world!\n" (gdb) print ascii_hello[0] $2 = 72 'H' (gdb) |
GDB uses the target character set for character and string literals you use in expressions:
(gdb) print '+' $3 = 43 '+' (gdb) |
The ASCII character set uses the number 43 to encode the `+' character.
GDB relies on the user to tell it which character set the
target program uses. If we print ibm1047_hello while our target
character set is still ASCII, we get jibberish:
(gdb) print ibm1047_hello $4 = 0x4016a8 "\310\205\223\223\226k@\246\226\231\223\204Z%" (gdb) print ibm1047_hello[0] $5 = 200 '\310' (gdb) |
If we invoke the set target-charset followed by TABTAB,
GDB tells us the character sets it supports:
(gdb) set target-charset ASCII EBCDIC-US IBM1047 ISO-8859-1 (gdb) set target-charset |
We can select IBM1047 as our target character set, and examine the
program's strings again. Now the ASCII string is wrong, but
GDB translates the contents of ibm1047_hello from the
target character set, IBM1047, to the host character set,
ASCII, and they display correctly:
(gdb) set target-charset IBM1047 (gdb) show charset The current host character set is `ASCII'. The current target character set is `IBM1047'. (gdb) print ascii_hello $6 = 0x401698 "\110\145%%?\054\040\167?\162%\144\041\012" (gdb) print ascii_hello[0] $7 = 72 '\110' (gdb) print ibm1047_hello $8 = 0x4016a8 "Hello, world!\n" (gdb) print ibm1047_hello[0] $9 = 200 'H' (gdb) |
As above, GDB uses the target character set for character and string literals you use in expressions:
(gdb) print '+' $10 = 78 '+' (gdb) |
The IBM1047 character set uses the number 78 to encode the `+' character.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |