Subversion Repositories openrisc_me

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

INFO-DIR-SECTION Software development

START-INFO-DIR-ENTRY

* Gdb: (gdb).                     The GNU debugger.

END-INFO-DIR-ENTRY

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

1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,

2010 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.3 or

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

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

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

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

   (a) The FSF's Back-Cover Text is: "You are free to copy and modify

this GNU Manual.  Buying copies from GNU Press supports the FSF in

developing GNU and promoting software freedom."

   This file documents the GNU debugger GDB.

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

Source-Level Debugger' for GDB (GDB) Version 7.2.

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

1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,

2010 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.3 or

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

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

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

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

   (a) The FSF's Back-Cover Text is: "You are free to copy and modify

this GNU Manual.  Buying copies from GNU Press supports the FSF in

developing GNU and promoting software freedom."

File: gdb.info,  Node: Registers,  Next: Floating Point Hardware,  Prev: Convenience Vars,  Up: Data

10.12 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

     and vector registers (in the selected stack frame).

`info all-registers'

     Print the names and values of all registers, including

     floating-point and vector registers (in the selected stack frame).

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

   Some machines have special registers whose contents can be

interpreted in several different ways.  For example, modern x86-based

machines have SSE and MMX registers that can hold several values packed

together in several different formats.  GDB refers to such registers in

`struct' notation:

     (gdb) print $xmm1

     $1 = {

       v4_float = {0, 3.43859137e-038, 1.54142831e-044, 1.821688e-044},

       v2_double = {9.92129282474342e-303, 2.7585945287983262e-313},

       v16_int8 = "\000\000\000\000\3706;\001\v\000\000\000\r\000\000",

       v8_int16 = {0, 0, 14072, 315, 11, 0, 13, 0},

       v4_int32 = {0, 20657912, 11, 13},

       v2_int64 = {88725056443645952, 55834574859},

       uint128 = 0x0000000d0000000b013b36f800000000

     }

To set values of such registers, you need to tell GDB which view of the

register you wish to change, as if you were assigning value to a

`struct' member:

      (gdb) set $xmm1.uint128 = 0x000000000000000000000000FFFFFFFF

   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,  Next: Vector Unit,  Prev: Registers,  Up: Data

10.13 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: Vector Unit,  Next: OS Information,  Prev: Floating Point Hardware,  Up: Data

10.14 Vector Unit

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

Depending on the configuration, GDB may be able to give you more

information about the status of the vector unit.

`info vector'

     Display information about the vector unit.  The exact contents and

     layout vary depending on the hardware.

File: gdb.info,  Node: OS Information,  Next: Memory Region Attributes,  Prev: Vector Unit,  Up: Data

10.15 Operating System Auxiliary Information

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

GDB provides interfaces to useful OS facilities that can help you debug

your program.

   When GDB runs on a "Posix system" (such as GNU or Unix machines), it

interfaces with the inferior via the `ptrace' system call.  The

operating system creates a special sata structure, called `struct

user', for this interface.  You can use the command `info udot' to

display the contents of this data structure.

`info udot'

     Display the contents of the `struct user' maintained by the OS

     kernel for the program being debugged.  GDB displays the contents

     of `struct user' as a list of hex numbers, similar to the

     `examine' command.

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

targets, this functionality may further depend on the remote stub's

support of the `qXfer:auxv:read' packet, see *Note qXfer auxiliary

vector read::.

`info auxv'

     Display the auxiliary vector of the inferior, which can be either a

     live process or a core dump file.  GDB prints each tag value

     numerically, and also shows names and text descriptions for

     recognized tags.  Some values in the vector are numbers, some bit

     masks, and some pointers to strings or other data.  GDB displays

     each value in the most appropriate form for a recognized tag, and

     in hexadecimal for an unrecognized tag.

   On some targets, GDB can access operating-system-specific information

and display it to user, without interpretation.  For remote targets,

this functionality depends on the remote stub's support of the

`qXfer:osdata:read' packet, see *Note qXfer osdata read::.

`info os'

     List the types of OS information available for the target.  If the

     target does not return a list of possible types, this command will

     report an error.

`info os processes'

     Display the list of processes on the target.  For each process,

     GDB prints the process identifier, the name of the user, and the

     command corresponding to the process.

File: gdb.info,  Node: Memory Region Attributes,  Next: Dump/Restore Files,  Prev: OS Information,  Up: Data

10.16 Memory Region Attributes

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

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

default the description of memory regions is fetched from the target

(if the current target supports this), but the user can override the

fetched regions.

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

     Define a memory region bounded by LOWER and UPPER with attributes

     ATTRIBUTES..., and add it to the list of regions monitored by GDB.

     Note that UPPER == 0 is a special case: it is treated as the

     target's maximum memory address.  (0xffff on 16 bit targets,

     0xffffffff on 32 bit targets, etc.)

`mem auto'

     Discard any user changes to the memory regions and use

     target-supplied regions, if available, or no regions if the target

     does not support.

`delete mem NUMS...'

     Remove memory regions NUMS... from the list of regions monitored

     by GDB.

`disable mem NUMS...'

     Disable monitoring of memory regions NUMS....  A disabled memory

     region is not forgotten.  It may be enabled again later.

`enable mem NUMS...'

     Enable monitoring of memory regions NUMS....

`info mem'

     Print a table of all defined memory regions, with the following

     columns for each region:

    _Memory Region Number_

    _Enabled or Disabled._

          Enabled memory regions are marked with `y'.  Disabled memory

          regions are marked with `n'.

    _Lo Address_

          The address defining the inclusive lower bound of the memory

          region.

    _Hi Address_

          The address defining the exclusive upper bound of the memory

          region.

    _Attributes_

          The list of attributes set for this memory region.

10.16.1 Attributes

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

10.16.1.1 Memory Access Mode

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

The access mode attributes set whether GDB may make read or write

accesses to a memory region.

   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'

     Memory is read only.

`wo'

     Memory is write only.

`rw'

     Memory is read/write.  This is the default.

10.16.1.2 Memory Access Size

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

The access size attribute tells GDB to use specific sized accesses in

the memory region.  Often memory mapped device registers require

specific sized accesses.  If no access size attribute is specified, GDB

may use accesses of any size.

`8'

     Use 8 bit memory accesses.

`16'

     Use 16 bit memory accesses.

`32'

     Use 32 bit memory accesses.

`64'

     Use 64 bit memory accesses.

10.16.1.3 Data Cache

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

The data cache attributes set whether GDB will cache target memory.

While this generally improves performance by reducing debug protocol

overhead, it can lead to incorrect results because GDB does not know

about volatile variables or memory mapped device registers.

`cache'

     Enable GDB to cache target memory.

`nocache'

     Disable GDB from caching target memory.  This is the default.

10.16.2 Memory Access Checking

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

GDB can be instructed to refuse accesses to memory that is not

explicitly described.  This can be useful if accessing such regions has

undesired effects for a specific target, or to provide better error

checking.  The following commands control this behaviour.

`set mem inaccessible-by-default [on|off]'

     If `on' is specified, make  GDB treat memory not explicitly

     described by the memory ranges as non-existent and refuse accesses

     to such memory.  The checks are only performed if there's at least

     one memory range defined.  If `off' is specified, make GDB treat

     the memory not explicitly described by the memory ranges as RAM.

     The default value is `on'.

`show mem inaccessible-by-default'

     Show the current handling of accesses to unknown memory.

File: gdb.info,  Node: Dump/Restore Files,  Next: Core File Generation,  Prev: Memory Region Attributes,  Up: Data

10.17 Copy Between Memory and a File

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

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'

     Dump the contents of memory from START_ADDR to END_ADDR, or the

     value of EXPR, to FILENAME in the given format.

     The FORMAT parameter may be any one of:

    `binary'

          Raw binary form.

    `ihex'

          Intel hex format.

    `srec'

          Motorola S-record format.

    `tekhex'

          Tektronix Hex format.

     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'

     Append the contents of memory from START_ADDR to END_ADDR, or the

     value of EXPR, to the file FILENAME, in raw binary form.  (GDB can

     only append data to files in raw binary form.)

`restore FILENAME [binary] BIAS START END'

     Restore the contents of file FILENAME into memory.  The `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.

File: gdb.info,  Node: Core File Generation,  Next: Character Sets,  Prev: Dump/Restore Files,  Up: Data

10.18 How to Produce a Core File from Your Program

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

A "core file" or "core dump" is a file that records the memory image of

a running process and its process status (register values etc.).  Its

primary use is post-mortem debugging of a program that crashed while it

ran outside a debugger.  A program that crashes automatically produces

a core file, unless this feature is disabled by the user.  *Note

Files::, for information on invoking GDB in the post-mortem debugging

mode.

   Occasionally, you may wish to produce a core file of the program you

are debugging in order to preserve a snapshot of its state.  GDB has a

special command for that.

`generate-core-file [FILE]'

`gcore [FILE]'

     Produce a core dump of the inferior process.  The optional argument

     FILE specifies the file name where to put the core dump.  If not

     specified, the file name defaults to `core.PID', where PID is the

     inferior process ID.

     Note that this command is implemented only for some systems (as of

     this writing, GNU/Linux, FreeBSD, Solaris, Unixware, and S390).

File: gdb.info,  Node: Character Sets,  Next: Caching Remote Data,  Prev: Core File Generation,  Up: Data

10.19 Character Sets

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

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 (*note 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 the current target character set to CHARSET.  To display the

     list of supported target character sets, type

     `set target-charset '.

`set host-charset CHARSET'

     Set the current host character set to 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.  On some systems, GDB cannot

     automatically determine the appropriate host character set.  In

     this case, GDB uses `UTF-8'.

     GDB can only use certain character sets as its host character set.

     If you type `set target-charset ', GDB will list the

     host character sets it supports.

`set charset CHARSET'

     Set the current host and target character sets to CHARSET.  As

     above, if you type `set charset ', GDB will list the

     names of the character sets that can be used for both host and

     target.

`show charset'

     Show the names of the current host and target character sets.

`show host-charset'

     Show the name of the current host character set.

`show target-charset'

     Show the name of the current target character set.

`set target-wide-charset CHARSET'

     Set the current target's wide character set to CHARSET.  This is

     the character set used by the target's `wchar_t' type.  To display

     the list of supported wide character sets, type

     `set target-wide-charset '.

`show target-wide-charset'

     Show the name of the current target's wide character set.

   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 

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

File: gdb.info,  Node: Caching Remote Data,  Next: Searching Memory,  Prev: Character Sets,  Up: Data

10.20 Caching Data of Remote Targets

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

GDB caches data exchanged between the debugger and a remote target

(*note Remote Debugging::).  Such caching generally improves

performance, because it reduces the overhead of the remote protocol by

bundling memory reads and writes into large chunks.  Unfortunately,

simply caching everything would lead to incorrect results, since GDB

does not necessarily know anything about volatile values, memory-mapped

I/O addresses, etc.  Furthermore, in non-stop mode (*note Non-Stop

Mode::) memory can be changed _while_ a gdb command is executing.

Therefore, by default, GDB only caches data known to be on the stack(1).

Other regions of memory can be explicitly marked as cacheable; see

*note Memory Region Attributes::.

`set remotecache on'

`set remotecache off'

     This option no longer does anything; it exists for compatibility

     with old scripts.

`show remotecache'

     Show the current state of the obsolete remotecache flag.

`set stack-cache on'

`set stack-cache off'

     Enable or disable caching of stack accesses.  When `ON', use

     caching.  By default, this option is `ON'.

`show stack-cache'

     Show the current state of data caching for memory accesses.

`info dcache [line]'

     Print the information about the data cache performance.  The

     information displayed includes the dcache width and depth, and for

     each cache line, its number, address, and how many times it was

     referenced.  This command is useful for debugging the data cache

     operation.

     If a line number is specified, the contents of that line will be

     printed in hex.

   ---------- Footnotes ----------

   (1) In non-stop mode, it is moderately rare for a running thread to

modify the stack of a stopped thread in a way that would interfere with

a backtrace, and caching of stack reads provides a significant speed up

of remote backtraces.

File: gdb.info,  Node: Searching Memory,  Prev: Caching Remote Data,  Up: Data

10.21 Search Memory

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

Memory can be searched for a particular sequence of bytes with the

`find' command.

`find [/SN] START_ADDR, +LEN, VAL1 [, VAL2, ...]'

`find [/SN] START_ADDR, END_ADDR, VAL1 [, VAL2, ...]'

     Search memory for the sequence of bytes specified by VAL1, VAL2,

     etc.  The search begins at address START_ADDR and continues for

     either LEN bytes or through to END_ADDR inclusive.

   S and N are optional parameters.  They may be specified in either

order, apart or together.

S, search query size

     The size of each search query value.

    `b'

          bytes

    `h'

          halfwords (two bytes)

    `w'

          words (four bytes)

    `g'

          giant words (eight bytes)

     All values are interpreted in the current language.  This means,

     for example, that if the current source language is C/C++ then

     searching for the string "hello" includes the trailing '\0'.

     If the value size is not specified, it is taken from the value's

     type in the current language.  This is useful when one wants to

     specify the search pattern as a mixture of types.  Note that this

     means, for example, that in the case of C-like languages a search

     for an untyped 0x42 will search for `(int) 0x42' which is

     typically four bytes.

N, maximum number of finds

     The maximum number of matches to print.  The default is to print

     all finds.

   You can use strings as search values.  Quote them with double-quotes

(`"').  The string value is copied into the search pattern byte by

byte, regardless of the endianness of the target and the size

specification.

   The address of each match found is printed as well as a count of the

number of matches found.

   The address of the last value found is stored in convenience variable

`$_'.  A count of the number of matches is stored in `$numfound'.

   For example, if stopped at the `printf' in this function:

     void

     hello ()

     {

       static char hello[] = "hello-hello";

       static struct { char c; short s; int i; }

         __attribute__ ((packed)) mixed

         = { 'c', 0x1234, 0x87654321 };

       printf ("%s\n", hello);

     }

you get during debugging:

     (gdb) find &hello[0], +sizeof(hello), "hello"

     0x804956d 

     1 pattern found

     (gdb) find &hello[0], +sizeof(hello), 'h', 'e', 'l', 'l', 'o'

     0x8049567 

     0x804956d 

     2 patterns found

     (gdb) find /b1 &hello[0], +sizeof(hello), 'h', 0x65, 'l'

     0x8049567 

     1 pattern found

     (gdb) find &mixed, +sizeof(mixed), (char) 'c', (short) 0x1234, (int) 0x87654321

     0x8049560 

     1 pattern found

     (gdb) print $numfound

     $1 = 1

     (gdb) print $_

     $2 = (void *) 0x8049560

File: gdb.info,  Node: Optimized Code,  Next: Macros,  Prev: Data,  Up: Top

11 Debugging Optimized Code

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

Almost all compilers support optimization.  With optimization disabled,

the compiler generates assembly code that corresponds directly to your

source code, in a simplistic way.  As the compiler applies more

powerful optimizations, the generated assembly code diverges from your

original source code.  With help from debugging information generated

by the compiler, GDB can map from the running program back to

constructs from your original source.

   GDB is more accurate with optimization disabled.  If you can

recompile without optimization, it is easier to follow the progress of

your program during debugging.  But, there are many cases where you may

need to debug an optimized version.

   When you debug a program compiled with `-g -O', remember that the

optimizer has rearranged your code; the debugger shows you what is

really there.  Do not be too surprised when the execution path does not

exactly match your source file!  An extreme example: if you define a

variable, but never use it, GDB never sees that variable--because the

compiler optimizes it out of existence.

   Some things do not work as well with `-g -O' as with just `-g',

particularly on machines with instruction scheduling.  If in doubt,

recompile with `-g' alone, and if this fixes the problem, please report

it to us as a bug (including a test case!).  *Note Variables::, for

more information about debugging optimized code.

* Menu:

* Inline Functions::            How GDB presents inlining

File: gdb.info,  Node: Inline Functions,  Up: Optimized Code

11.1 Inline Functions

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

"Inlining" is an optimization that inserts a copy of the function body

directly at each call site, instead of jumping to a shared routine.

GDB displays inlined functions just like non-inlined functions.  They

appear in backtraces.  You can view their arguments and local

variables, step into them with `step', skip them with `next', and

escape from them with `finish'.  You can check whether a function was

inlined by using the `info frame' command.

   For GDB to support inlined functions, the compiler must record

information about inlining in the debug information -- GCC using the

DWARF 2 format does this, and several other compilers do also.  GDB

only supports inlined functions when using DWARF 2.  Versions of GCC

before 4.1 do not emit two required attributes (`DW_AT_call_file' and

`DW_AT_call_line'); GDB does not display inlined function calls with

earlier versions of GCC.  It instead displays the arguments and local

variables of inlined functions as local variables in the caller.

   The body of an inlined function is directly included at its call

site; unlike a non-inlined function, there are no instructions devoted

to the call.  GDB still pretends that the call site and the start of

the inlined function are different instructions.  Stepping to the call

site shows the call site, and then stepping again shows the first line

of the inlined function, even though no additional instructions are

executed.

   This makes source-level debugging much clearer; you can see both the

context of the call and then the effect of the call.  Only stepping by

a single instruction using `stepi' or `nexti' does not do this; single

instruction steps always show the inlined body.

   There are some ways that GDB does not pretend that inlined function

calls are the same as normal calls:

   * You cannot set breakpoints on inlined functions.  GDB either

     reports that there is no symbol with that name, or else sets the

     breakpoint only on non-inlined copies of the function.  This

     limitation will be removed in a future version of GDB; until then,

     set a breakpoint by line number on the first line of the inlined

     function instead.

   * Setting breakpoints at the call site of an inlined function may not

     work, because the call site does not contain any code.  GDB may

     incorrectly move the breakpoint to the next line of the enclosing

     function, after the call.  This limitation will be removed in a

     future version of GDB; until then, set a breakpoint on an earlier

     line or inside the inlined function instead.

   * GDB cannot locate the return value of inlined calls after using

     the `finish' command.  This is a limitation of compiler-generated

     debugging information; after `finish', you can step to the next

     line and print a variable where your program stored the return

     value.

File: gdb.info,  Node: Macros,  Next: Tracepoints,  Prev: Optimized Code,  Up: Top

12 C Preprocessor Macros

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

Some languages, such as C and C++, provide a way to define and invoke

"preprocessor macros" which expand into strings of tokens.  GDB can

evaluate expressions containing macro invocations, show the result of

macro expansion, and show a macro's definition, including where it was

defined.

   You may need to compile your program specially to provide GDB with

information about preprocessor macros.  Most compilers do not include

macros in their debugging information, even when you compile with the

`-g' flag.  *Note Compilation::.

   A program may define a macro at one point, remove that definition

later, and then provide a different definition after that.  Thus, at

different points in the program, a macro may have different

definitions, or have no definition at all.  If there is a current stack

frame, GDB uses the macros in scope at that frame's source code line.

Otherwise, GDB uses the macros in scope at the current listing location;

see *Note List::.

   Whenever GDB evaluates an expression, it always expands any macro

invocations present in the expression.  GDB also provides the following

commands for working with macros explicitly.

`macro expand EXPRESSION'

`macro exp EXPRESSION'

     Show the results of expanding all preprocessor macro invocations in

     EXPRESSION.  Since GDB simply expands macros, but does not parse

     the result, EXPRESSION need not be a valid expression; it can be

     any string of tokens.

`macro expand-once EXPRESSION'

`macro exp1 EXPRESSION'

     (This command is not yet implemented.)  Show the results of

     expanding those preprocessor macro invocations that appear

     explicitly in EXPRESSION.  Macro invocations appearing in that

     expansion are left unchanged.  This command allows you to see the

     effect of a particular macro more clearly, without being confused