| Index: gdb/doc/gdb.info-2
|
| diff --git a/gdb/doc/gdb.info-2 b/gdb/doc/gdb.info-2
|
| index 83604686ee62bf345a371ad633c1d4ea9a700f55..3e94550058c6dccb2f1d7049ab0bff8c9a512d16 100644
|
| --- a/gdb/doc/gdb.info-2
|
| +++ b/gdb/doc/gdb.info-2
|
| @@ -1,13 +1,12 @@
|
| -This is gdb.info, produced by makeinfo version 4.8 from ./gdb.texinfo.
|
| +This is gdb.info, produced by makeinfo version 4.13 from ./gdb.texinfo.
|
|
|
| INFO-DIR-SECTION Software development
|
| START-INFO-DIR-ENTRY
|
| * Gdb: (gdb). The GNU debugger.
|
| +* gdbserver: (gdb) Server. The GNU debugging server.
|
| 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 2011, 2012 Free Software Foundation, Inc.
|
| + Copyright (C) 1988-2013 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
|
| @@ -23,11 +22,9 @@ developing GNU and promoting software freedom."
|
| This file documents the GNU debugger GDB.
|
|
|
| This is the Tenth Edition, of `Debugging with GDB: the GNU
|
| -Source-Level Debugger' for GDB (GDB) Version 7.5.1.
|
| +Source-Level Debugger' for GDB (GDB) Version 7.6.50.20131211-cvs.
|
|
|
| - Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,
|
| -1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
|
| -2010 2011, 2012 Free Software Foundation, Inc.
|
| + Copyright (C) 1988-2013 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
|
| @@ -41,6 +38,475 @@ this GNU Manual. Buying copies from GNU Press supports the FSF in
|
| developing GNU and promoting software freedom."
|
|
|
|
|
| +File: gdb.info, Node: Variables, Next: Arrays, Prev: Ambiguous Expressions, Up: Data
|
| +
|
| +10.3 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 by
|
| +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
|
| +
|
| + The `::' notation is normally used for referring to static
|
| +variables, since you typically disambiguate uses of local variables in
|
| +functions by selecting the appropriate frame and using the simple name
|
| +of the variable. However, you may also use this notation to refer to
|
| +local variables in frames enclosing the selected frame:
|
| +
|
| + void
|
| + foo (int a)
|
| + {
|
| + if (a < 10)
|
| + bar (a);
|
| + else
|
| + process (a); /* Stop here */
|
| + }
|
| +
|
| + int
|
| + bar (int a)
|
| + {
|
| + foo (a + 5);
|
| + }
|
| +
|
| +For example, if there is a breakpoint at the commented line, here is
|
| +what you might see when the program stops after executing the call
|
| +`bar(0)':
|
| +
|
| + (gdb) p a
|
| + $1 = 10
|
| + (gdb) p bar::a
|
| + $2 = 5
|
| + (gdb) up 2
|
| + #2 0x080483d0 in foo (a=5) at foobar.c:12
|
| + (gdb) p a
|
| + $3 = 5
|
| + (gdb) p bar::a
|
| + $4 = 0
|
| +
|
| + These uses of `::' are very rarely in conflict with the very similar
|
| +use of the same notation in C++. When they are in conflict, the C++
|
| +meaning takes precedence; however, this can be overridden by quoting
|
| +the file or function name with single quotes.
|
| +
|
| + For example, suppose the program is stopped in a method of a class
|
| +that has a field named `includefile', and there is also an include file
|
| +named `includefile' that defines a variable, `some_global'.
|
| +
|
| + (gdb) p includefile
|
| + $1 = 23
|
| + (gdb) p includefile::some_global
|
| + A syntax error in expression, near `'.
|
| + (gdb) p 'includefile'::some_global
|
| + $2 = 27
|
| +
|
| + _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. *Note Compilation::, for more information on choosing compiler
|
| +options. *Note C and C++: C, for more information about debug info
|
| +formats that are best suited to C++ programs.
|
| +
|
| + If you ask to print an object whose contents are unknown to GDB,
|
| +e.g., because its data type is not completely specified by the debug
|
| +information, GDB will say `<incomplete type>'. *Note incomplete type:
|
| +Symbols, for more about this.
|
| +
|
| + If you append `@entry' string to a function parameter name you get
|
| +its value at the time the function got called. If the value is not
|
| +available an error message is printed. Entry values are available only
|
| +with some compilers. Entry values are normally also printed at the
|
| +function parameter list according to *note set print entry-values::.
|
| +
|
| + Breakpoint 1, d (i=30) at gdb.base/entry-value.c:29
|
| + 29 i++;
|
| + (gdb) next
|
| + 30 e (i);
|
| + (gdb) print i
|
| + $1 = 31
|
| + (gdb) print i@entry
|
| + $2 = 30
|
| +
|
| + Strings are identified as arrays of `char' values without specified
|
| +signedness. Arrays of either `signed char' or `unsigned char' get
|
| +printed as arrays of 1 byte sized integers. `-fsigned-char' or
|
| +`-funsigned-char' GCC options have no effect as GDB defines literal
|
| +string type `"char"' as `char' without a sign. For program code
|
| +
|
| + char var0[] = "A";
|
| + signed char var1[] = "A";
|
| +
|
| + You get during debugging
|
| + (gdb) print var0
|
| + $1 = "A"
|
| + (gdb) print var1
|
| + $2 = {65 'A', 0 '\0'}
|
| +
|
| +
|
| +File: gdb.info, Node: Arrays, Next: Output Formats, Prev: Variables, Up: Data
|
| +
|
| +10.4 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
|
| +
|
| +10.5 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>
|
| +
|
| + The command `info symbol 0x54320' yields similar results. *Note
|
| + info symbol: Symbols.
|
| +
|
| +`c'
|
| + Regard as an integer and print it as a character constant. This
|
| + prints both the numerical value and its character representation.
|
| + The character representation is replaced with the octal escape
|
| + `\nnn' for characters outside the 7-bit ASCII range.
|
| +
|
| + Without this format, GDB displays `char', `unsigned char', and
|
| + `signed char' data as character constants. Single-byte members of
|
| + vectors are displayed as integer data.
|
| +
|
| +`f'
|
| + Regard the bits of the value as a floating point number and print
|
| + using typical floating point syntax.
|
| +
|
| +`s'
|
| + Regard as a string, if possible. With this format, pointers to
|
| + single-byte data are displayed as null-terminated strings and
|
| + arrays of single-byte data are displayed as fixed-length strings.
|
| + Other values are displayed in their natural types.
|
| +
|
| + Without this format, GDB displays pointers to and arrays of
|
| + `char', `unsigned char', and `signed char' as strings.
|
| + Single-byte members of a vector are displayed as an integer array.
|
| +
|
| +`z'
|
| + Like `x' formatting, the value is treated as an integer and
|
| + printed as hexadecimal, but leading zeros are printed to pad the
|
| + value to the size of the integer type.
|
| +
|
| +`r'
|
| + Print using the `raw' formatting. By default, GDB will use a
|
| + Python-based pretty-printer, if one is available (*note Pretty
|
| + Printing::). This typically results in a higher-level display of
|
| + the value's contents. The `r' format bypasses any Python
|
| + pretty-printer which might exist.
|
| +
|
| + 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
|
| +
|
| +10.6 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' (`x',
|
| + `d', `u', `o', `t', `a', `c', `f', `s'), and in addition `i' (for
|
| + machine instructions). 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 `i' format, the
|
| + unit size is ignored and is normally not written. For the `s'
|
| + format, the unit size defaults to `b', unless it is explicitly
|
| + given. Use `x /hs' to display 16-bit char strings and `x /ws' to
|
| + display 32-bit strings. The next use of `x /s' will again display
|
| + 8-bit strings. Note that the results depend on the programming
|
| + language of the current compilation unit. If the language is C,
|
| + the `s' modifier will use the UTF-16 encoding while `w' will use
|
| + UTF-32. The encoding is set by the programming language and cannot
|
| + be altered.
|
| +
|
| +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.
|
| +For convenience, especially when used with the `display' command, the
|
| +`i' format also prints branch delay slot instructions, if any, beyond
|
| +the count specified, which immediately follow the last instruction that
|
| +is within the count. 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'.
|
| +
|
| + When examining machine instructions, the instruction at current
|
| +program counter is shown with a `=>' marker. For example:
|
| +
|
| + (gdb) x/5i $pc-6
|
| + 0x804837f <main+11>: mov %esp,%ebp
|
| + 0x8048381 <main+13>: push %ecx
|
| + 0x8048382 <main+14>: sub $0x4,%esp
|
| + => 0x8048385 <main+17>: movl $0x8048460,(%esp)
|
| + 0x804838c <main+24>: call 0x80482d4 <puts@plt>
|
| +
|
| + 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.
|
| +
|
| + When you are debugging a program running on a remote target machine
|
| +(*note Remote Debugging::), you may wish to verify the program's image
|
| +in the remote machine's memory against the executable file you
|
| +downloaded to the target. The `compare-sections' command is provided
|
| +for such situations.
|
| +
|
| +`compare-sections [SECTION-NAME]'
|
| + Compare the data of a loadable section SECTION-NAME in the
|
| + executable file of the program being debugged with the same
|
| + section in the remote machine's memory, and report any mismatches.
|
| + With no arguments, compares all loadable sections. This command's
|
| + availability depends on the target's support for the `"qCRC"'
|
| + remote request.
|
| +
|
| +
|
| File: gdb.info, Node: Auto Display, Next: Print Settings, Prev: Memory, Up: Data
|
|
|
| 10.7 Automatic Display
|
| @@ -207,10 +673,12 @@ and source file that corresponds to each instruction.
|
| printed is reasonably close to the closest earlier symbol:
|
|
|
| `set print max-symbolic-offset MAX-OFFSET'
|
| +`set print max-symbolic-offset unlimited'
|
| 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.
|
| + than MAX-OFFSET. The default is `unlimited', which tells GDB to
|
| + always print the symbolic form of an address if any symbol precedes
|
| + it. Zero is equivalent to `unlimited'.
|
|
|
| `show print max-symbolic-offset'
|
| Ask how large the maximum offset is that GDB prints in a symbolic
|
| @@ -276,12 +744,14 @@ print symbol on':
|
| arrays.
|
|
|
| `set print elements NUMBER-OF-ELEMENTS'
|
| +`set print elements unlimited'
|
| 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.
|
| + GDB starts, this limit is set to 200. Setting NUMBER-OF-ELEMENTS
|
| + to `unlimited' or zero means that the number of elements to print
|
| + is unlimited.
|
|
|
| `show print elements'
|
| Display the number of elements of a large array that GDB will
|
| @@ -328,6 +798,17 @@ print symbol on':
|
| Show how the value of arguments should be displayed when printing
|
| a frame.
|
|
|
| +`set print raw frame-arguments on'
|
| + Print frame arguments in raw, non pretty-printed, form.
|
| +
|
| +`set print raw frame-arguments off'
|
| + Print frame arguments in pretty-printed form, if there is a
|
| + pretty-printer for the value (*note Pretty Printing::), otherwise
|
| + print the value in raw form. This is the default.
|
| +
|
| +`show print raw frame-arguments'
|
| + Show whether to print frame arguments in raw form.
|
| +
|
| `set print entry-values VALUE'
|
| Set printing of frame argument values at function entry. In some
|
| cases GDB can determine the value of function argument which was
|
| @@ -422,21 +903,22 @@ print symbol on':
|
| #0 invalid (val=<optimized out>)
|
|
|
| For analysis messages on possible failures of frame argument
|
| - values at function entry resolution see *Note set debug
|
| + values at function entry resolution see *note set debug
|
| entry-values::.
|
|
|
| `show print entry-values'
|
| Show the method being used for printing of frame argument values
|
| at function entry.
|
|
|
| -`set print repeats'
|
| +`set print repeats NUMBER-OF-REPEATS'
|
| +`set print repeats unlimited'
|
| Set the threshold for suppressing display of repeated array
|
| elements. When the number of consecutive identical elements of an
|
| array exceeds the threshold, GDB prints the string `"<repeats N
|
| times>"', where N is the number of identical repetitions, instead
|
| of displaying the identical elements themselves. Setting the
|
| - threshold to zero will cause all elements to be individually
|
| - printed. The default threshold is 10.
|
| + threshold to `unlimited' or zero will cause all elements to be
|
| + individually printed. The default threshold is 10.
|
|
|
| `show print repeats'
|
| Display the current threshold for printing repeated identical
|
| @@ -556,11 +1038,11 @@ These settings are of interest when debugging C++ programs:
|
|
|
| `auto'
|
| Allow GDB to choose a decoding style by inspecting your
|
| - program.
|
| + program. This is the default.
|
|
|
| `gnu'
|
| Decode based on the GNU C++ compiler (`g++') encoding
|
| - algorithm. This is the default.
|
| + algorithm.
|
|
|
| `hp'
|
| Decode based on the HP ANSI C++ (`aCC') encoding algorithm.
|
| @@ -864,7 +1346,7 @@ remains 4 even though the value of `x' has changed.
|
| as `show values +'.
|
|
|
|
|
| -File: gdb.info, Node: Convenience Vars, Next: Registers, Prev: Value History, Up: Data
|
| +File: gdb.info, Node: Convenience Vars, Next: Convenience Funs, Prev: Value History, Up: Data
|
|
|
| 10.11 Convenience Variables
|
| ===========================
|
| @@ -902,7 +1384,8 @@ its current value.
|
|
|
| `show convenience'
|
| Print a list of convenience variables used so far, and their
|
| - values. Abbreviated `show conv'.
|
| + values, as well as a list of the convenience functions.
|
| + Abbreviated `show conv'.
|
|
|
| `init-if-undefined $VARIABLE = EXPRESSION'
|
| Set a convenience variable if it has not already been set. This
|
| @@ -942,8 +1425,62 @@ values likely to be useful.
|
| 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.
|
| + When the program being debugged terminates normally, GDB
|
| + automatically sets this variable to the exit code of the program,
|
| + and resets `$_exitsignal' to `void'.
|
| +
|
| +`$_exitsignal'
|
| + When the program being debugged dies due to an uncaught signal,
|
| + GDB automatically sets this variable to that signal's number, and
|
| + resets `$_exitcode' to `void'.
|
| +
|
| + To distinguish between whether the program being debugged has
|
| + exited (i.e., `$_exitcode' is not `void') or signalled (i.e.,
|
| + `$_exitsignal' is not `void'), the convenience function `$_isvoid'
|
| + can be used (*note Convenience Functions: Convenience Funs.). For
|
| + example, considering the following source code:
|
| +
|
| + #include <signal.h>
|
| +
|
| + int
|
| + main (int argc, char *argv[])
|
| + {
|
| + raise (SIGALRM);
|
| + return 0;
|
| + }
|
| +
|
| + A valid way of telling whether the program being debugged has
|
| + exited or signalled would be:
|
| +
|
| + (gdb) define has_exited_or_signalled
|
| + Type commands for definition of ``has_exited_or_signalled''.
|
| + End with a line saying just ``end''.
|
| + >if $_isvoid ($_exitsignal)
|
| + >echo The program has exited\n
|
| + >else
|
| + >echo The program has signalled\n
|
| + >end
|
| + >end
|
| + (gdb) run
|
| + Starting program:
|
| +
|
| + Program terminated with signal SIGALRM, Alarm clock.
|
| + The program no longer exists.
|
| + (gdb) has_exited_or_signalled
|
| + The program has signalled
|
| +
|
| + As can be seen, GDB correctly informs that the program being
|
| + debugged has signalled, since it calls `raise' and raises a
|
| + `SIGALRM' signal. If the program being debugged had not called
|
| + `raise', then GDB would report a normal exit:
|
| +
|
| + (gdb) has_exited_or_signalled
|
| + The program has exited
|
| +
|
| +`$_exception'
|
| + The variable `$_exception' is set to the exception object being
|
| + thrown at an exception-related catchpoint. *Note Set
|
| + Catchpoints::.
|
|
|
| `$_probe_argc'
|
| `$_probe_arg0...$_probe_arg11'
|
| @@ -973,18 +1510,99 @@ values likely to be useful.
|
| begins with a dollar sign, GDB searches for a user or system name
|
| first, before it searches for a convenience variable.
|
|
|
| - GDB also supplies some "convenience functions". These have a syntax
|
| +
|
| +File: gdb.info, Node: Convenience Funs, Next: Registers, Prev: Convenience Vars, Up: Data
|
| +
|
| +10.12 Convenience Functions
|
| +===========================
|
| +
|
| +GDB also supplies some "convenience functions". These have a syntax
|
| similar to convenience variables. A convenience function can be used
|
| in an expression just like an ordinary function; however, a convenience
|
| function is implemented internally to GDB.
|
|
|
| + These functions do not require GDB to be configured with `Python'
|
| +support, which means that they are always available.
|
| +
|
| +`$_isvoid (EXPR)'
|
| + Return one if the expression EXPR is `void'. Otherwise it returns
|
| + zero.
|
| +
|
| + A `void' expression is an expression where the type of the result
|
| + is `void'. For example, you can examine a convenience variable
|
| + (see *note Convenience Variables: Convenience Vars.) to check
|
| + whether it is `void':
|
| +
|
| + (gdb) print $_exitcode
|
| + $1 = void
|
| + (gdb) print $_isvoid ($_exitcode)
|
| + $2 = 1
|
| + (gdb) run
|
| + Starting program: ./a.out
|
| + [Inferior 1 (process 29572) exited normally]
|
| + (gdb) print $_exitcode
|
| + $3 = 0
|
| + (gdb) print $_isvoid ($_exitcode)
|
| + $4 = 0
|
| +
|
| + In the example above, we used `$_isvoid' to check whether
|
| + `$_exitcode' is `void' before and after the execution of the
|
| + program being debugged. Before the execution there is no exit
|
| + code to be examined, therefore `$_exitcode' is `void'. After the
|
| + execution the program being debugged returned zero, therefore
|
| + `$_exitcode' is zero, which means that it is not `void' anymore.
|
| +
|
| + The `void' expression can also be a call of a function from the
|
| + program being debugged. For example, given the following function:
|
| +
|
| + void
|
| + foo (void)
|
| + {
|
| + }
|
| +
|
| + The result of calling it inside GDB is `void':
|
| +
|
| + (gdb) print foo ()
|
| + $1 = void
|
| + (gdb) print $_isvoid (foo ())
|
| + $2 = 1
|
| + (gdb) set $v = foo ()
|
| + (gdb) print $v
|
| + $3 = void
|
| + (gdb) print $_isvoid ($v)
|
| + $4 = 1
|
| +
|
| +
|
| + These functions require GDB to be configured with `Python' support.
|
| +
|
| +`$_memeq(BUF1, BUF2, LENGTH)'
|
| + Returns one if the LENGTH bytes at the addresses given by BUF1 and
|
| + BUF2 are equal. Otherwise it returns zero.
|
| +
|
| +`$_regex(STR, REGEX)'
|
| + Returns one if the string STR matches the regular expression
|
| + REGEX. Otherwise it returns zero. The syntax of the regular
|
| + expression is that specified by `Python''s regular expression
|
| + support.
|
| +
|
| +`$_streq(STR1, STR2)'
|
| + Returns one if the strings STR1 and STR2 are equal. Otherwise it
|
| + returns zero.
|
| +
|
| +`$_strlen(STR)'
|
| + Returns the length of string STR.
|
| +
|
| +
|
| + GDB provides the ability to list and get help on convenience
|
| +functions.
|
| +
|
| `help function'
|
| Print a list of all convenience functions.
|
|
|
|
|
| -File: gdb.info, Node: Registers, Next: Floating Point Hardware, Prev: Convenience Vars, Up: Data
|
| +File: gdb.info, Node: Registers, Next: Floating Point Hardware, Prev: Convenience Funs, Up: Data
|
|
|
| -10.12 Registers
|
| +10.13 Registers
|
| ===============
|
|
|
| You can refer to machine register contents, in expressions, as variables
|
| @@ -1082,10 +1700,28 @@ 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.
|
| + Usually ABIs reserve some registers as not needed to be saved by the
|
| +callee (a.k.a.: "caller-saved", "call-clobbered" or "volatile"
|
| +registers). It may therefore not be possible for GDB to know the value
|
| +a register had before the call (in other words, in the outer frame), if
|
| +the register value has since been changed by the callee. GDB tries to
|
| +deduce where the inner frame saved ("callee-saved") registers, from the
|
| +debug info, unwind info, or the machine code generated by your
|
| +compiler. If some register is not saved, and GDB knows the register is
|
| +"caller-saved" (via its own knowledge of the ABI, or because the
|
| +debug/unwind info explicitly says the register's value is undefined),
|
| +GDB displays `<not saved>' as the register's value. With targets that
|
| +GDB has no knowledge of the register saving convention, if a register
|
| +was not saved by the callee, then its value and location in the outer
|
| +frame are assumed to be the same of the inner frame. This is usually
|
| +harmless, because if the register is call-clobbered, the caller either
|
| +does not care what is in the register after the call, or has code to
|
| +restore the value that it does care about. Note, however, that if you
|
| +change such a register in the outer frame, you may also be affecting
|
| +the inner frame. Also, the more "outer" the frame is you're looking
|
| +at, the more likely a call-clobbered register's value is to be wrong,
|
| +in the sense that it doesn't actually represent the value the register
|
| +had just before the call.
|
|
|
| ---------- Footnotes ----------
|
|
|
| @@ -1094,12 +1730,12 @@ 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.
|
| +*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
|
| +10.14 Floating Point Hardware
|
| =============================
|
|
|
| Depending on the configuration, GDB may be able to give you more
|
| @@ -1114,7 +1750,7 @@ information about the status of the floating point hardware.
|
|
|
| File: gdb.info, Node: Vector Unit, Next: OS Information, Prev: Floating Point Hardware, Up: Data
|
|
|
| -10.14 Vector Unit
|
| +10.15 Vector Unit
|
| =================
|
|
|
| Depending on the configuration, GDB may be able to give you more
|
| @@ -1127,24 +1763,12 @@ information about the status of the vector unit.
|
|
|
| File: gdb.info, Node: OS Information, Next: Memory Region Attributes, Prev: Vector Unit, Up: Data
|
|
|
| -10.15 Operating System Auxiliary Information
|
| +10.16 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
|
| @@ -1154,7 +1778,7 @@ 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
|
| +support of the `qXfer:auxv:read' packet, see *note qXfer auxiliary
|
| vector read::.
|
|
|
| `info auxv'
|
| @@ -1169,10 +1793,10 @@ vector read::.
|
| On some targets, GDB can access operating system-specific
|
| information and show it to you. The types of information available
|
| will differ depending on the type of operating system running on the
|
| -target. The mechanism used to fetch the data is described in *Note
|
| +target. The mechanism used to fetch the data is described in *note
|
| Operating System Information::. For remote targets, this functionality
|
| depends on the remote stub's support of the `qXfer:osdata:read' packet,
|
| -see *Note qXfer osdata read::.
|
| +see *note qXfer osdata read::.
|
|
|
| `info os INFOTYPE'
|
| Display OS information of the requested type.
|
| @@ -1263,7 +1887,7 @@ see *Note qXfer osdata read::.
|
|
|
| File: gdb.info, Node: Memory Region Attributes, Next: Dump/Restore Files, Prev: OS Information, Up: Data
|
|
|
| -10.16 Memory Region Attributes
|
| +10.17 Memory Region Attributes
|
| ==============================
|
|
|
| "Memory region attributes" allow you to describe special handling
|
| @@ -1326,10 +1950,10 @@ to enable, disable, or remove a memory region, you specify that number.
|
| _Attributes_
|
| The list of attributes set for this memory region.
|
|
|
| -10.16.1 Attributes
|
| +10.17.1 Attributes
|
| ------------------
|
|
|
| -10.16.1.1 Memory Access Mode
|
| +10.17.1.1 Memory Access Mode
|
| ............................
|
|
|
| The access mode attributes set whether GDB may make read or write
|
| @@ -1348,7 +1972,7 @@ from accessing memory.
|
| `rw'
|
| Memory is read/write. This is the default.
|
|
|
| -10.16.1.2 Memory Access Size
|
| +10.17.1.2 Memory Access Size
|
| ............................
|
|
|
| The access size attribute tells GDB to use specific sized accesses in
|
| @@ -1368,7 +1992,7 @@ may use accesses of any size.
|
| `64'
|
| Use 64 bit memory accesses.
|
|
|
| -10.16.1.3 Data Cache
|
| +10.17.1.3 Data Cache
|
| ....................
|
|
|
| The data cache attributes set whether GDB will cache target memory.
|
| @@ -1382,7 +2006,7 @@ about volatile variables or memory mapped device registers.
|
| `nocache'
|
| Disable GDB from caching target memory. This is the default.
|
|
|
| -10.16.2 Memory Access Checking
|
| +10.17.2 Memory Access Checking
|
| ------------------------------
|
|
|
| GDB can be instructed to refuse accesses to memory that is not
|
| @@ -1404,7 +2028,7 @@ checking. The following commands control this behaviour.
|
|
|
| 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
|
| +10.18 Copy Between Memory and a File
|
| ====================================
|
|
|
| You can use the commands `dump', `append', and `restore' to copy data
|
| @@ -1463,7 +2087,7 @@ append to binary files.
|
|
|
| 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
|
| +10.19 How to Produce a Core File from Your Program
|
| ==================================================
|
|
|
| A "core file" or "core dump" is a file that records the memory image of
|
| @@ -1486,12 +2110,12 @@ special command for that.
|
| inferior process ID.
|
|
|
| Note that this command is implemented only for some systems (as of
|
| - this writing, GNU/Linux, FreeBSD, Solaris, Unixware, and S390).
|
| + this writing, GNU/Linux, FreeBSD, Solaris, and S390).
|
|
|
|
|
| -File: gdb.info, Node: Character Sets, Next: Caching Remote Data, Prev: Core File Generation, Up: Data
|
| +File: gdb.info, Node: Character Sets, Next: Caching Target Data, Prev: Core File Generation, Up: Data
|
|
|
| -10.19 Character Sets
|
| +10.20 Character Sets
|
| ====================
|
|
|
| If the program you are debugging uses a different character set to
|
| @@ -1672,22 +2296,24 @@ literals you use in expressions:
|
| character.
|
|
|
|
|
| -File: gdb.info, Node: Caching Remote Data, Next: Searching Memory, Prev: Character Sets, Up: Data
|
| +File: gdb.info, Node: Caching Target Data, Next: Searching Memory, Prev: Character Sets, Up: Data
|
|
|
| -10.20 Caching Data of Remote Targets
|
| -====================================
|
| +10.21 Caching Data of 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::.
|
| +GDB caches data exchanged between the debugger and a target. Each
|
| +cache is associated with the address space of the inferior. *Note
|
| +Inferiors and Programs::, about inferior and address space. Such
|
| +caching generally improves performance in remote debugging (*note
|
| +Remote Debugging::), 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) or in the code segment. Other regions of memory can be
|
| +explicitly marked as cacheable; *note Memory Region Attributes::.
|
|
|
| `set remotecache on'
|
| `set remotecache off'
|
| @@ -1699,18 +2325,28 @@ Other regions of memory can be explicitly marked as cacheable; see
|
|
|
| `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'.
|
| + 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.
|
|
|
| +`set code-cache on'
|
| +`set code-cache off'
|
| + Enable or disable caching of code segment accesses. When `on',
|
| + use caching. By default, this option is `on'. This improves
|
| + performance of disassembly in remote debugging.
|
| +
|
| +`show code-cache'
|
| + Show the current state of target memory cache for code segment
|
| + 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.
|
| + Print the information about the performance of data cache of the
|
| + current inferior's address space. 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.
|
| @@ -1723,12 +2359,11 @@ Other regions of memory can be explicitly marked as cacheable; see
|
| Must be a power of 2.
|
|
|
| `show dcache size'
|
| - Show maximum number of dcache entries. See also *Note info
|
| - dcache: Caching Remote Data.
|
| + Show maximum number of dcache entries. *Note info dcache: Caching
|
| + Target Data.
|
|
|
| `show dcache line-size'
|
| - Show default size of dcache lines. See also *Note info dcache:
|
| - Caching Remote Data.
|
| + Show default size of dcache lines.
|
|
|
|
|
| ---------- Footnotes ----------
|
| @@ -1739,9 +2374,9 @@ 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
|
| +File: gdb.info, Node: Searching Memory, Prev: Caching Target Data, Up: Data
|
|
|
| -10.21 Search Memory
|
| +10.22 Search Memory
|
| ===================
|
|
|
| Memory can be searched for a particular sequence of bytes with the
|
| @@ -1787,9 +2422,8 @@ N, maximum number of finds
|
| 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 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.
|
| @@ -1959,7 +2593,7 @@ output:
|
| Locals at unknown address, Previous frame's sp is 0x7fffffffda30
|
|
|
| The detection of all the possible code path executions can find them
|
| -ambiguous. There is no execution history stored (possible *Note
|
| +ambiguous. There is no execution history stored (possible *note
|
| Reverse Execution:: is never used for this purpose) and the last known
|
| caller could have reached the known callee by multiple different jump
|
| sequences. In such case GDB still tries to show at least all the
|
| @@ -2081,7 +2715,7 @@ 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::.
|
| +see *note List::.
|
|
|
| Whenever GDB evaluates an expression, it always expands any macro
|
| invocations present in the expression. GDB also provides the following
|
| @@ -2304,7 +2938,7 @@ targets. *Note Targets::. In addition, your remote target must know
|
| how to collect trace data. This functionality is implemented in the
|
| remote stub; however, none of the stubs distributed with GDB support
|
| tracepoints as of this writing. The format of the remote packets used
|
| -to implement tracepoints are described in *Note Tracepoint Packets::.
|
| +to implement tracepoints are described in *note Tracepoint Packets::.
|
|
|
| It is also possible to get trace data from a file, in a manner
|
| reminiscent of corefiles; you specify the filename, and use `tfind' to
|
| @@ -2829,6 +3463,8 @@ File: gdb.info, Node: Listing Tracepoints, Next: Listing Static Tracepoint Mar
|
|
|
| * its passcount as given by the `passcount N' command
|
|
|
| + * the state about installed on target of each location
|
| +
|
| (gdb) info trace
|
| Num Type Disp Enb Address What
|
| 1 tracepoint keep y 0x0804ab57 in foo() at main.cxx:7
|
| @@ -2838,6 +3474,15 @@ File: gdb.info, Node: Listing Tracepoints, Next: Listing Static Tracepoint Mar
|
| collect globfoo2
|
| end
|
| pass count 1200
|
| + 2 tracepoint keep y <MULTIPLE>
|
| + collect $eip
|
| + 2.1 y 0x0804859c in func4 at change-loc.h:35
|
| + installed on target
|
| + 2.2 y 0xb7ffc480 in func4 at change-loc.h:35
|
| + installed on target
|
| + 2.3 y <PENDING> set_tracepoint
|
| + 3 tracepoint keep y 0x080485b1 in foo at change-loc.c:29
|
| + not installed on target
|
| (gdb)
|
|
|
| This command can be abbreviated `info tp'.
|
| @@ -3002,6 +3647,22 @@ on the fly, otherwise it will not take effect until the next run.
|
| a trace file.
|
|
|
|
|
| +`set trace-buffer-size N'
|
| +`set trace-buffer-size unlimited'
|
| + Request that the target use a trace buffer of N bytes. Not all
|
| + targets will honor the request; they may have a compiled-in size
|
| + for the trace buffer, or some other limitation. Set to a value of
|
| + `unlimited' or `-1' to let the target use whatever size it likes.
|
| + This is also the default.
|
| +
|
| +`show trace-buffer-size'
|
| + Show the current requested size for the trace buffer. Note that
|
| + this will only match the actual size if the target supports
|
| + size-setting, and was able to handle the requested size. For
|
| + instance, if the target can only change buffer size between runs,
|
| + this variable will not reflect the change until the next run
|
| + starts. Use `tstatus' to get a report of the actual buffer size.
|
| +
|
| `set trace-user TEXT'
|
|
|
| `show trace-user'
|
| @@ -3360,6 +4021,7 @@ trace data into a file, and later use that file as a source of trace
|
| data, via the `target tfile' command.
|
|
|
| `tsave [ -r ] FILENAME'
|
| +`tsave [-ctf] DIRNAME'
|
| Save the trace data to FILENAME. By default, this command assumes
|
| that FILENAME refers to the host filesystem, so if necessary GDB
|
| will copy raw trace data up from the target and then save it. If
|
| @@ -3367,15 +4029,36 @@ data, via the `target tfile' command.
|
| `-r' ("remote") to direct the target to save the data directly
|
| into FILENAME in its own filesystem, which may be more efficient
|
| if the trace buffer is very large. (Note, however, that `target
|
| - tfile' can only read from files accessible to the host.)
|
| + tfile' can only read from files accessible to the host.) By
|
| + default, this command will save trace frame in tfile format. You
|
| + can supply the optional argument `-ctf' to save date in CTF
|
| + format. The "Common Trace Format" (CTF) is proposed as a trace
|
| + format that can be shared by multiple debugging and tracing tools.
|
| + Please go to <http://www.efficios.com/ctf> to get more information.
|
|
|
| `target tfile FILENAME'
|
| - Use the file named FILENAME as a source of trace data. Commands
|
| - that examine data work as they do with a live target, but it is not
|
| - possible to run any new trace experiments. `tstatus' will report
|
| - the state of the trace run at the moment the data was saved, as
|
| - well as the current trace frame you are examining. FILENAME must
|
| - be on a filesystem accessible to the host.
|
| +`target ctf DIRNAME'
|
| + Use the file named FILENAME or directory named DIRNAME as a source
|
| + of trace data. Commands that examine data work as they do with a
|
| + live target, but it is not possible to run any new trace
|
| + experiments. `tstatus' will report the state of the trace run at
|
| + the moment the data was saved, as well as the current trace frame
|
| + you are examining. FILENAME or DIRNAME must be on a filesystem
|
| + accessible to the host.
|
| +
|
| + (gdb) target ctf ctf.ctf
|
| + (gdb) tfind
|
| + Found trace frame 0, tracepoint 2
|
| + 39 ++a; /* set tracepoint 1 here */
|
| + (gdb) tdump
|
| + Data collected at tracepoint 2, trace frame 0:
|
| + i = 0
|
| + a = 0
|
| + b = 1 '\001'
|
| + c = {"123", "456", "789", "123", "456", "789"}
|
| + d = {{{a = 1, b = 2}, {a = 3, b = 4}}, {{a = 5, b = 6}, {a = 7, b = 8}}}
|
| + (gdb) p b
|
| + $1 = 1
|
|
|
|
|
|
|
| @@ -3484,7 +4167,7 @@ program:
|
| be relocated and its symbols defined as if the overlay were at its
|
| mapped address. You can use GNU linker scripts to specify
|
| different load and relocation addresses for pieces of your
|
| - program; see *Note Overlay Description: (ld.info)Overlay
|
| + program; see *note Overlay Description: (ld.info)Overlay
|
| Description.
|
|
|
| * The procedure for loading executable files onto your system must
|
| @@ -3561,7 +4244,7 @@ abbreviate this as `ov' or `ovly'. The commands are:
|
| `overlay auto'
|
| Enable "automatic" overlay debugging. In this mode, GDB consults
|
| a data structure the overlay manager maintains in the inferior to
|
| - see which overlays are mapped. For details, see *Note Automatic
|
| + see which overlays are mapped. For details, see *note Automatic
|
| Overlay Debugging::.
|
|
|
| `overlay load-target'
|
| @@ -3925,25 +4608,18 @@ File: gdb.info, Node: Checks, Next: Supported Languages, Prev: Show, Up: Lan
|
| 15.3 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: Supported Languages, for
|
| -the default settings of supported languages.
|
| +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.
|
| +
|
| + By default GDB checks for these errors according to the rules of the
|
| +current source language. 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.
|
|
|
| * Menu:
|
|
|
| @@ -3956,64 +4632,44 @@ File: gdb.info, Node: Type Checking, Next: Range Checking, Up: Checks
|
| 15.3.1 An Overview of Type Checking
|
| -----------------------------------
|
|
|
| -Some languages, such as Modula-2, are strongly typed, meaning that the
|
| +Some languages, such as C and C++, 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
|
| + int klass::my_method(char *b) { return b ? 1 : 2; }
|
| +
|
| + (gdb) print obj.my_method (0)
|
| + $1 = 2
|
| 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: Supported Languages, for further
|
| -details on specific languages.
|
| -
|
| - GDB provides some additional commands for controlling the type
|
| -checker:
|
| + (gdb) print obj.my_method (0x1234)
|
| + Cannot resolve method klass::my_method to any overloaded instance
|
|
|
| -`set check type auto'
|
| - Set type checking on or off based on the current working language.
|
| - *Note Supported Languages: Supported Languages, for the default
|
| - settings for each language.
|
| + The second example fails because in C++ the integer constant
|
| +`0x1234' is not type-compatible with the pointer parameter type.
|
| +
|
| + For the expressions you use in GDB commands, you can tell GDB to not
|
| +enforce strict type checking or to treat any mismatches as errors and
|
| +abandon the expression; When type checking is disabled, GDB
|
| +successfully evaluates expressions like the second example above.
|
| +
|
| + Even if type checking is 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 which make little sense to evaluate anyway.
|
| +
|
| + GDB provides some additional commands for controlling type checking:
|
|
|
| `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
|
| + Set strict type checking on or off. 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.
|
| +`show check type'
|
| + Show the current setting of type checking and whether GDB is
|
| + enforcing strict type checking rules.
|
|
|
|
|
| File: gdb.info, Node: Range Checking, Prev: Type Checking, Up: Checks
|
| @@ -4381,7 +5037,7 @@ GDB expression handling can interpret most C++ expressions.
|
| explicit function signature to call an overloaded function, as in
|
| p 'foo(char,int)'('x', 13)
|
|
|
| - The GDB command-completion facility can simplify this; see *Note
|
| + The GDB command-completion facility can simplify this; see *note
|
| Command Completion: Completion.
|
|
|
| 4. GDB understands variables declared as C++ references; you can use
|
| @@ -4411,10 +5067,9 @@ File: gdb.info, Node: C Defaults, Next: C Checks, Prev: C Plus Plus Expressio
|
| 15.4.1.4 C and C++ Defaults
|
| ...........................
|
|
|
| -If you allow GDB to set type and range checking automatically, they
|
| -both default to `off' whenever the working language changes to C or
|
| -C++. This happens regardless of whether you or GDB selects the working
|
| -language.
|
| +If you allow GDB to set range checking automatically, it defaults to
|
| +`off' whenever the working language changes to C or C++. This happens
|
| +regardless of whether you or GDB selects the working language.
|
|
|
| If you allow GDB to set the language automatically, it recognizes
|
| source files whose names end with `.c', `.C', or `.cc', etc, and when
|
| @@ -4428,16 +5083,10 @@ File: gdb.info, Node: C Checks, Next: Debugging C, Prev: C Defaults, Up: C
|
| 15.4.1.5 C and C++ Type and Range Checks
|
| ........................................
|
|
|
| -By default, when GDB parses C or C++ expressions, type checking is not
|
| -used. However, if you turn type checking on, GDB considers two
|
| -variables type equivalent if:
|
| -
|
| - * The two variables are structured and have the same structure,
|
| - union, or enumerated tag.
|
| -
|
| - * The two variables have the same type name, or types that have been
|
| - declared equivalent through `typedef'.
|
| -
|
| +By default, when GDB parses C or C++ expressions, strict type checking
|
| +is used. However, if you turn type checking off, GDB will allow
|
| +certain non-standard conversions, such as promoting integer constants
|
| +to pointers.
|
|
|
| Range checking, if turned on, is done on mathematical operations.
|
| Array indices are not checked, since they are often used to index a
|
| @@ -4478,6 +5127,7 @@ designed specifically for use with C++. Here is a summary:
|
| of any special classes. *Note Setting Breakpoints: Set Breaks.
|
|
|
| `catch throw'
|
| +`catch rethrow'
|
| `catch catch'
|
| Debug C++ exception handling using these commands. *Note Setting
|
| Catchpoints: Set Catchpoints.
|
| @@ -4515,7 +5165,7 @@ designed specifically for use with C++. Here is a summary:
|
| Enable overload resolution for C++ expression evaluation. The
|
| default is on. For overloaded functions, GDB evaluates the
|
| arguments and searches for a function whose signature matches the
|
| - argument types, using the standard C++ conversion rules (see *Note
|
| + argument types, using the standard C++ conversion rules (see *note
|
| C++ Expressions: C Plus Plus Expressions, for details). If it
|
| cannot find a match, it emits a message.
|
|
|
| @@ -4552,8 +5202,8 @@ extension to support decimal floating-point arithmetic.
|
|
|
| There are two encodings in use, depending on the architecture: BID
|
| (Binary Integer Decimal) for x86 and x86-64, and DPD (Densely Packed
|
| -Decimal) for PowerPC. GDB will use the appropriate encoding for the
|
| -configured target.
|
| +Decimal) for PowerPC and S/390. GDB will use the appropriate encoding
|
| +for the configured target.
|
|
|
| Because of a limitation in `libdecnumber', the library used by GDB
|
| to manipulate decimal floating point numbers, it is not possible to
|
| @@ -4566,7 +5216,7 @@ underflow, overflow and divide by zero exceptions.
|
|
|
| In the PowerPC architecture, GDB provides a set of pseudo-registers
|
| to inspect `_Decimal128' values stored in floating point registers.
|
| -See *Note PowerPC: PowerPC. for more details.
|
| +See *note PowerPC: PowerPC. for more details.
|
|
|
|
|
| File: gdb.info, Node: D, Next: Go, Prev: C, Up: Supported Languages
|
| @@ -4625,8 +5275,8 @@ File: gdb.info, Node: Objective-C, Next: OpenCL C, Prev: Go, Up: Supported L
|
| ------------------
|
|
|
| This section provides information about some commands and command
|
| -options that are useful for debugging Objective-C code. See also *Note
|
| -info classes: Symbols, and *Note info selectors: Symbols, for a few
|
| +options that are useful for debugging Objective-C code. See also *note
|
| +info classes: Symbols, and *note info selectors: Symbols, for a few
|
| more commands specific to Objective-C support.
|
|
|
| * Menu:
|
| @@ -4803,7 +5453,7 @@ File: gdb.info, Node: Fortran Defaults, Next: Special Fortran Commands, Prev:
|
|
|
| Fortran symbols are usually case-insensitive, so GDB by default uses
|
| case-insensitive matches for Fortran symbols. You can change that with
|
| -the `set case-insensitive' command, see *Note Symbols::, for the
|
| +the `set case-insensitive' command, see *note Symbols::, for the
|
| details.
|
|
|
|
|
| @@ -5382,6 +6032,7 @@ difficult.
|
| * Omissions from Ada:: Restrictions on the Ada expression syntax.
|
| * Additions to Ada:: Extensions of the Ada expression syntax.
|
| * Stopping Before Main Program:: Debugging the program during elaboration.
|
| +* Ada Exceptions:: Ada Exceptions
|
| * Ada Tasks:: Listing and setting breakpoints in tasks.
|
| * Ada Tasks and Core Files:: Tasking Support when Debugging Core Files
|
| * Ravenscar Profile:: Tasking Support when using the Ravenscar
|
| @@ -5629,7 +6280,7 @@ additions specific to Ada:
|
|
|
|
|
|
|
| -File: gdb.info, Node: Stopping Before Main Program, Next: Ada Tasks, Prev: Additions to Ada, Up: Ada
|
| +File: gdb.info, Node: Stopping Before Main Program, Next: Ada Exceptions, Prev: Additions to Ada, Up: Ada
|
|
|
| 15.4.9.4 Stopping at the Very Beginning
|
| .......................................
|
| @@ -5641,9 +6292,43 @@ Manual, the elaboration code is invoked from a procedure called
|
| simply use the following two commands: `tbreak adainit' and `run'.
|
|
|
|
|
| -File: gdb.info, Node: Ada Tasks, Next: Ada Tasks and Core Files, Prev: Stopping Before Main Program, Up: Ada
|
| +File: gdb.info, Node: Ada Exceptions, Next: Ada Tasks, Prev: Stopping Before Main Program, Up: Ada
|
| +
|
| +15.4.9.5 Ada Exceptions
|
| +.......................
|
| +
|
| +A command is provided to list all Ada exceptions:
|
| +
|
| +`info exceptions'
|
| +`info exceptions REGEXP'
|
| + The `info exceptions' command allows you to list all Ada exceptions
|
| + defined within the program being debugged, as well as their
|
| + addresses. With a regular expression, REGEXP, as argument, only
|
| + those exceptions whose names match REGEXP are listed.
|
| +
|
| + Below is a small example, showing how the command can be used, first
|
| +without argument, and next with a regular expression passed as an
|
| +argument.
|
| +
|
| + (gdb) info exceptions
|
| + All defined Ada exceptions:
|
| + constraint_error: 0x613da0
|
| + program_error: 0x613d20
|
| + storage_error: 0x613ce0
|
| + tasking_error: 0x613ca0
|
| + const.aint_global_e: 0x613b00
|
| + (gdb) info exceptions const.aint
|
| + All Ada exceptions matching regular expression "const.aint":
|
| + constraint_error: 0x613da0
|
| + const.aint_global_e: 0x613b00
|
| +
|
| + It is also possible to ask GDB to stop your program's execution when
|
| +an exception is raised. For more details, see *note Set Catchpoints::.
|
| +
|
| +
|
| +File: gdb.info, Node: Ada Tasks, Next: Ada Tasks and Core Files, Prev: Ada Exceptions, Up: Ada
|
|
|
| -15.4.9.5 Extensions for Ada Tasks
|
| +15.4.9.6 Extensions for Ada Tasks
|
| .................................
|
|
|
| Support for Ada tasks is analogous to that for threads (*note
|
| @@ -5777,7 +6462,7 @@ Threads::). GDB provides the following task-related commands:
|
| `break LINESPEC task TASKNO if ...'
|
| These commands are like the `break ... thread ...' command (*note
|
| Thread Stops::). LINESPEC specifies source lines, as described in
|
| - *Note Specify Location::.
|
| + *note Specify Location::.
|
|
|
| Use the qualifier `task TASKNO' with a breakpoint command to
|
| specify that you only want GDB to stop the program when a
|
| @@ -5819,7 +6504,7 @@ Threads::). GDB provides the following task-related commands:
|
|
|
| File: gdb.info, Node: Ada Tasks and Core Files, Next: Ravenscar Profile, Prev: Ada Tasks, Up: Ada
|
|
|
| -15.4.9.6 Tasking Support when Debugging Core Files
|
| +15.4.9.7 Tasking Support when Debugging Core Files
|
| ..................................................
|
|
|
| When inspecting a core file, as opposed to debugging a live program,
|
| @@ -5838,7 +6523,7 @@ of the core file before inspecting it with GDB.
|
|
|
| File: gdb.info, Node: Ravenscar Profile, Next: Ada Glitches, Prev: Ada Tasks and Core Files, Up: Ada
|
|
|
| -15.4.9.7 Tasking Support when using the Ravenscar Profile
|
| +15.4.9.8 Tasking Support when using the Ravenscar Profile
|
| .........................................................
|
|
|
| The "Ravenscar Profile" is a subset of the Ada tasking features,
|
| @@ -5865,7 +6550,7 @@ requirements.
|
|
|
| File: gdb.info, Node: Ada Glitches, Prev: Ravenscar Profile, Up: Ada
|
|
|
| -15.4.9.8 Known Peculiarities of Ada Mode
|
| +15.4.9.9 Known Peculiarities of Ada Mode
|
| ........................................
|
|
|
| Besides the omissions listed previously (*note Omissions from Ada::),
|
| @@ -5982,6 +6667,36 @@ looks up the value of `x' in the scope of the file `foo.c'.
|
| This command shows the current setting of case sensitivity for
|
| symbols lookups.
|
|
|
| +`set print type methods'
|
| +`set print type methods on'
|
| +`set print type methods off'
|
| + Normally, when GDB prints a class, it displays any methods
|
| + declared in that class. You can control this behavior either by
|
| + passing the appropriate flag to `ptype', or using `set print type
|
| + methods'. Specifying `on' will cause GDB to display the methods;
|
| + this is the default. Specifying `off' will cause GDB to omit the
|
| + methods.
|
| +
|
| +`show print type methods'
|
| + This command shows the current setting of method display when
|
| + printing classes.
|
| +
|
| +`set print type typedefs'
|
| +`set print type typedefs on'
|
| +`set print type typedefs off'
|
| + Normally, when GDB prints a class, it displays any typedefs
|
| + defined in that class. You can control this behavior either by
|
| + passing the appropriate flag to `ptype', or using `set print type
|
| + typedefs'. Specifying `on' will cause GDB to display the typedef
|
| + definitions; this is the default. Specifying `off' will cause GDB
|
| + to omit the typedef definitions. Note that this controls whether
|
| + the typedef definition itself is printed, not whether typedef
|
| + names are substituted when printing other types.
|
| +
|
| +`show print type typedefs'
|
| + This command shows the current setting of typedef display when
|
| + printing classes.
|
| +
|
| `info address SYMBOL'
|
| Describe where the data for SYMBOL is stored. For a register
|
| variable, this says which register it is kept in. For a
|
| @@ -6012,7 +6727,7 @@ looks up the value of `x' in the scope of the file `foo.c'.
|
| (gdb) info symbol 0x2aaaac2811cf
|
| __read_nocancel + 6 in section .text of /usr/lib64/libc.so.6
|
|
|
| -`whatis [ARG]'
|
| +`whatis[/FLAGS] [ARG]'
|
| Print the data type of ARG, which can be either an expression or a
|
| name of a data type. With no argument, print the data type of
|
| `$', the last value in the value history.
|
| @@ -6040,7 +6755,34 @@ looks up the value of `x' in the scope of the file `foo.c'.
|
| CLASS-NAME', `struct STRUCT-TAG', `union UNION-TAG' or `enum
|
| ENUM-TAG'.
|
|
|
| -`ptype [ARG]'
|
| + FLAGS can be used to modify how the type is displayed. Available
|
| + flags are:
|
| +
|
| + `r'
|
| + Display in "raw" form. Normally, GDB substitutes template
|
| + parameters and typedefs defined in a class when printing the
|
| + class' members. The `/r' flag disables this.
|
| +
|
| + `m'
|
| + Do not print methods defined in the class.
|
| +
|
| + `M'
|
| + Print methods defined in the class. This is the default, but
|
| + the flag exists in case you change the default with `set
|
| + print type methods'.
|
| +
|
| + `t'
|
| + Do not print typedefs defined in the class. Note that this
|
| + controls whether the typedef definition itself is printed,
|
| + not whether typedef names are substituted when printing other
|
| + types.
|
| +
|
| + `T'
|
| + Print typedefs defined in the class. This is the default,
|
| + but the flag exists in case you change the default with `set
|
| + print type typedefs'.
|
| +
|
| +`ptype[/FLAGS] [ARG]'
|
| `ptype' accepts the same arguments as `whatis', but prints a
|
| detailed description of the type, instead of just the name of the
|
| type. *Note Expressions: Expressions.
|
| @@ -6119,6 +6861,19 @@ looks up the value of `x' in the scope of the file `foo.c'.
|
| `whatis', it does not print a detailed description; second, it
|
| lists all source files where a type is defined.
|
|
|
| +`info type-printers'
|
| + Versions of GDB that ship with Python scripting enabled may have
|
| + "type printers" available. When using `ptype' or `whatis', these
|
| + printers are consulted when the name of a type is needed. *Note
|
| + Type Printing API::, for more information on writing type printers.
|
| +
|
| + `info type-printers' displays all the available type printers.
|
| +
|
| +`enable type-printer NAME...'
|
| +
|
| +`disable type-printer NAME...'
|
| + These commands can be used to enable or disable type printers.
|
| +
|
| `info scope LOCATION'
|
| List all the variables local to a particular scope. This command
|
| accepts a LOCATION argument--a function name, a source line, or an
|
| @@ -6137,7 +6892,7 @@ looks up the value of `x' in the scope of the file `foo.c'.
|
| Symbol repeat is a local variable at frame offset -8, length 4.
|
|
|
| This command is especially useful for determining what data to
|
| - collect during a "trace experiment", see *Note collect: Tracepoint
|
| + collect during a "trace experiment", see *note collect: Tracepoint
|
| Actions.
|
|
|
| `info source'
|
| @@ -6401,11 +7156,13 @@ it stopped, with the `continue' command. You can instead continue at
|
| an address of your own choosing, with the following commands:
|
|
|
| `jump LINESPEC'
|
| +`j LINESPEC'
|
| `jump LOCATION'
|
| +`j LOCATION'
|
| Resume execution at line LINESPEC or at address given by LOCATION.
|
| Execution stops again immediately if there is a breakpoint there.
|
| - *Note Specify Location::, for a description of the different
|
| - forms of LINESPEC and LOCATION. It is common practice to use the
|
| + *Note Specify Location::, for a description of the different forms
|
| + of LINESPEC and LOCATION. It is common practice to use the
|
| `tbreak' command in conjunction with `jump'. *Note Setting
|
| Breakpoints: Set Breaks.
|
|
|
| @@ -6449,9 +7206,9 @@ File: gdb.info, Node: Signaling, Next: Returning, Prev: Jumping, Up: Alterin
|
|
|
| Alternatively, if SIGNAL is zero, continue execution without
|
| giving a signal. This is useful when your program stopped on
|
| - account of a signal and would ordinary see the signal when resumed
|
| - with the `continue' command; `signal 0' causes it to resume
|
| - without a signal.
|
| + account of a signal and would ordinarily see the signal when
|
| + resumed with the `continue' command; `signal 0' causes it to
|
| + resume without a signal.
|
|
|
| `signal' does not repeat when you press <RET> a second time after
|
| executing the command.
|
| @@ -6644,825 +7401,8 @@ the core dump file.
|
|
|
| * Files:: Commands to specify files
|
| * Separate Debug Files:: Debugging information in separate files
|
| +* MiniDebugInfo:: Debugging information in a special section
|
| * Index Files:: Index files speed up GDB
|
| * Symbol Errors:: Errors reading symbol files
|
| * Data Files:: GDB data files
|
|
|
| -
|
| -File: gdb.info, Node: Files, Next: Separate Debug Files, Up: GDB Files
|
| -
|
| -18.1 Commands to Specify Files
|
| -==============================
|
| -
|
| -You may want to specify executable and core dump file names. The usual
|
| -way to do this is at start-up time, using the arguments to GDB's
|
| -start-up commands (*note Getting In and Out of GDB: Invocation.).
|
| -
|
| - Occasionally it is necessary to change to a different file during a
|
| -GDB session. Or you may run GDB and forget to specify a file you want
|
| -to use. Or you are debugging a remote target via `gdbserver' (*note
|
| -file: Server.). In these situations the GDB commands to specify new
|
| -files are useful.
|
| -
|
| -`file FILENAME'
|
| - Use FILENAME as the program to be debugged. It is read for its
|
| - symbols and for the contents of pure memory. It is also the
|
| - program executed when you use the `run' command. If you do not
|
| - specify a directory and the file is not found in the GDB working
|
| - directory, GDB uses the environment variable `PATH' as a list of
|
| - directories to search, just as the shell does when looking for a
|
| - program to run. You can change the value of this variable, for
|
| - both GDB and your program, using the `path' command.
|
| -
|
| - You can load unlinked object `.o' files into GDB using the `file'
|
| - command. You will not be able to "run" an object file, but you
|
| - can disassemble functions and inspect variables. Also, if the
|
| - underlying BFD functionality supports it, you could use `gdb
|
| - -write' to patch object files using this technique. Note that GDB
|
| - can neither interpret nor modify relocations in this case, so
|
| - branches and some initialized variables will appear to go to the
|
| - wrong place. But this feature is still handy from time to time.
|
| -
|
| -`file'
|
| - `file' with no argument makes GDB discard any information it has
|
| - on both executable file and the symbol table.
|
| -
|
| -`exec-file [ FILENAME ]'
|
| - Specify that the program to be run (but not the symbol table) is
|
| - found in FILENAME. GDB searches the environment variable `PATH'
|
| - if necessary to locate your program. Omitting FILENAME means to
|
| - discard information on the executable file.
|
| -
|
| -`symbol-file [ FILENAME ]'
|
| - Read symbol table information from file FILENAME. `PATH' is
|
| - searched when necessary. Use the `file' command to get both symbol
|
| - table and program to run from the same file.
|
| -
|
| - `symbol-file' with no argument clears out GDB information on your
|
| - program's symbol table.
|
| -
|
| - The `symbol-file' command causes GDB to forget the contents of
|
| - some breakpoints and auto-display expressions. This is because
|
| - they may contain pointers to the internal data recording symbols
|
| - and data types, which are part of the old symbol table data being
|
| - discarded inside GDB.
|
| -
|
| - `symbol-file' does not repeat if you press <RET> again after
|
| - executing it once.
|
| -
|
| - When GDB is configured for a particular environment, it
|
| - understands debugging information in whatever format is the
|
| - standard generated for that environment; you may use either a GNU
|
| - compiler, or other compilers that adhere to the local conventions.
|
| - Best results are usually obtained from GNU compilers; for example,
|
| - using `GCC' you can generate debugging information for optimized
|
| - code.
|
| -
|
| - For most kinds of object files, with the exception of old SVR3
|
| - systems using COFF, the `symbol-file' command does not normally
|
| - read the symbol table in full right away. Instead, it scans the
|
| - symbol table quickly to find which source files and which symbols
|
| - are present. The details are read later, one source file at a
|
| - time, as they are needed.
|
| -
|
| - The purpose of this two-stage reading strategy is to make GDB
|
| - start up faster. For the most part, it is invisible except for
|
| - occasional pauses while the symbol table details for a particular
|
| - source file are being read. (The `set verbose' command can turn
|
| - these pauses into messages if desired. *Note Optional Warnings
|
| - and Messages: Messages/Warnings.)
|
| -
|
| - We have not implemented the two-stage strategy for COFF yet. When
|
| - the symbol table is stored in COFF format, `symbol-file' reads the
|
| - symbol table data in full right away. Note that "stabs-in-COFF"
|
| - still does the two-stage strategy, since the debug info is actually
|
| - in stabs format.
|
| -
|
| -`symbol-file [ -readnow ] FILENAME'
|
| -`file [ -readnow ] FILENAME'
|
| - You can override the GDB two-stage strategy for reading symbol
|
| - tables by using the `-readnow' option with any of the commands that
|
| - load symbol table information, if you want to be sure GDB has the
|
| - entire symbol table available.
|
| -
|
| -`core-file [FILENAME]'
|
| -`core'
|
| - Specify the whereabouts of a core dump file to be used as the
|
| - "contents of memory". Traditionally, core files contain only some
|
| - parts of the address space of the process that generated them; GDB
|
| - can access the executable file itself for other parts.
|
| -
|
| - `core-file' with no argument specifies that no core file is to be
|
| - used.
|
| -
|
| - Note that the core file is ignored when your program is actually
|
| - running under GDB. So, if you have been running your program and
|
| - you wish to debug a core file instead, you must kill the
|
| - subprocess in which the program is running. To do this, use the
|
| - `kill' command (*note Killing the Child Process: Kill Process.).
|
| -
|
| -`add-symbol-file FILENAME ADDRESS'
|
| -`add-symbol-file FILENAME ADDRESS [ -readnow ]'
|
| -`add-symbol-file FILENAME ADDRESS -s SECTION ADDRESS ...'
|
| - The `add-symbol-file' command reads additional symbol table
|
| - information from the file FILENAME. You would use this command
|
| - when FILENAME has been dynamically loaded (by some other means)
|
| - into the program that is running. ADDRESS should be the memory
|
| - address at which the file has been loaded; GDB cannot figure this
|
| - out for itself. You can additionally specify an arbitrary number
|
| - of `-s SECTION ADDRESS' pairs, to give an explicit section name
|
| - and base address for that section. You can specify any ADDRESS as
|
| - an expression.
|
| -
|
| - The symbol table of the file FILENAME is added to the symbol table
|
| - originally read with the `symbol-file' command. You can use the
|
| - `add-symbol-file' command any number of times; the new symbol data
|
| - thus read keeps adding to the old. To discard all old symbol data
|
| - instead, use the `symbol-file' command without any arguments.
|
| -
|
| - Although FILENAME is typically a shared library file, an
|
| - executable file, or some other object file which has been fully
|
| - relocated for loading into a process, you can also load symbolic
|
| - information from relocatable `.o' files, as long as:
|
| -
|
| - * the file's symbolic information refers only to linker symbols
|
| - defined in that file, not to symbols defined by other object
|
| - files,
|
| -
|
| - * every section the file's symbolic information refers to has
|
| - actually been loaded into the inferior, as it appears in the
|
| - file, and
|
| -
|
| - * you can determine the address at which every section was
|
| - loaded, and provide these to the `add-symbol-file' command.
|
| -
|
| - Some embedded operating systems, like Sun Chorus and VxWorks, can
|
| - load relocatable files into an already running program; such
|
| - systems typically make the requirements above easy to meet.
|
| - However, it's important to recognize that many native systems use
|
| - complex link procedures (`.linkonce' section factoring and C++
|
| - constructor table assembly, for example) that make the
|
| - requirements difficult to meet. In general, one cannot assume
|
| - that using `add-symbol-file' to read a relocatable object file's
|
| - symbolic information will have the same effect as linking the
|
| - relocatable object file into the program in the normal way.
|
| -
|
| - `add-symbol-file' does not repeat if you press <RET> after using
|
| - it.
|
| -
|
| -`add-symbol-file-from-memory ADDRESS'
|
| - Load symbols from the given ADDRESS in a dynamically loaded object
|
| - file whose image is mapped directly into the inferior's memory.
|
| - For example, the Linux kernel maps a `syscall DSO' into each
|
| - process's address space; this DSO provides kernel-specific code for
|
| - some system calls. The argument can be any expression whose
|
| - evaluation yields the address of the file's shared object file
|
| - header. For this command to work, you must have used
|
| - `symbol-file' or `exec-file' commands in advance.
|
| -
|
| -`add-shared-symbol-files LIBRARY-FILE'
|
| -`assf LIBRARY-FILE'
|
| - The `add-shared-symbol-files' command can currently be used only
|
| - in the Cygwin build of GDB on MS-Windows OS, where it is an alias
|
| - for the `dll-symbols' command (*note Cygwin Native::). GDB
|
| - automatically looks for shared libraries, however if GDB does not
|
| - find yours, you can invoke `add-shared-symbol-files'. It takes
|
| - one argument: the shared library's file name. `assf' is a
|
| - shorthand alias for `add-shared-symbol-files'.
|
| -
|
| -`section SECTION ADDR'
|
| - The `section' command changes the base address of the named
|
| - SECTION of the exec file to ADDR. This can be used if the exec
|
| - file does not contain section addresses, (such as in the `a.out'
|
| - format), or when the addresses specified in the file itself are
|
| - wrong. Each section must be changed separately. The `info files'
|
| - command, described below, lists all the sections and their
|
| - addresses.
|
| -
|
| -`info files'
|
| -`info target'
|
| - `info files' and `info target' are synonymous; both print the
|
| - current target (*note Specifying a Debugging Target: Targets.),
|
| - including the names of the executable and core dump files
|
| - currently in use by GDB, and the files from which symbols were
|
| - loaded. The command `help target' lists all possible targets
|
| - rather than current ones.
|
| -
|
| -`maint info sections'
|
| - Another command that can give you extra information about program
|
| - sections is `maint info sections'. In addition to the section
|
| - information displayed by `info files', this command displays the
|
| - flags and file offset of each section in the executable and core
|
| - dump files. In addition, `maint info sections' provides the
|
| - following command options (which may be arbitrarily combined):
|
| -
|
| - `ALLOBJ'
|
| - Display sections for all loaded object files, including
|
| - shared libraries.
|
| -
|
| - `SECTIONS'
|
| - Display info only for named SECTIONS.
|
| -
|
| - `SECTION-FLAGS'
|
| - Display info only for sections for which SECTION-FLAGS are
|
| - true. The section flags that GDB currently knows about are:
|
| - `ALLOC'
|
| - Section will have space allocated in the process when
|
| - loaded. Set for all sections except those containing
|
| - debug information.
|
| -
|
| - `LOAD'
|
| - Section will be loaded from the file into the child
|
| - process memory. Set for pre-initialized code and data,
|
| - clear for `.bss' sections.
|
| -
|
| - `RELOC'
|
| - Section needs to be relocated before loading.
|
| -
|
| - `READONLY'
|
| - Section cannot be modified by the child process.
|
| -
|
| - `CODE'
|
| - Section contains executable code only.
|
| -
|
| - `DATA'
|
| - Section contains data only (no executable code).
|
| -
|
| - `ROM'
|
| - Section will reside in ROM.
|
| -
|
| - `CONSTRUCTOR'
|
| - Section contains data for constructor/destructor lists.
|
| -
|
| - `HAS_CONTENTS'
|
| - Section is not empty.
|
| -
|
| - `NEVER_LOAD'
|
| - An instruction to the linker to not output the section.
|
| -
|
| - `COFF_SHARED_LIBRARY'
|
| - A notification to the linker that the section contains
|
| - COFF shared library information.
|
| -
|
| - `IS_COMMON'
|
| - Section contains common symbols.
|
| -
|
| -`set trust-readonly-sections on'
|
| - Tell GDB that readonly sections in your object file really are
|
| - read-only (i.e. that their contents will not change). In that
|
| - case, GDB can fetch values from these sections out of the object
|
| - file, rather than from the target program. For some targets
|
| - (notably embedded ones), this can be a significant enhancement to
|
| - debugging performance.
|
| -
|
| - The default is off.
|
| -
|
| -`set trust-readonly-sections off'
|
| - Tell GDB not to trust readonly sections. This means that the
|
| - contents of the section might change while the program is running,
|
| - and must therefore be fetched from the target when needed.
|
| -
|
| -`show trust-readonly-sections'
|
| - Show the current setting of trusting readonly sections.
|
| -
|
| - All file-specifying commands allow both absolute and relative file
|
| -names as arguments. GDB always converts the file name to an absolute
|
| -file name and remembers it that way.
|
| -
|
| - GDB supports GNU/Linux, MS-Windows, HP-UX, SunOS, SVr4, Irix, and
|
| -IBM RS/6000 AIX shared libraries.
|
| -
|
| - On MS-Windows GDB must be linked with the Expat library to support
|
| -shared libraries. *Note Expat::.
|
| -
|
| - GDB automatically loads symbol definitions from shared libraries
|
| -when you use the `run' command, or when you examine a core file.
|
| -(Before you issue the `run' command, GDB does not understand references
|
| -to a function in a shared library, however--unless you are debugging a
|
| -core file).
|
| -
|
| - On HP-UX, if the program loads a library explicitly, GDB
|
| -automatically loads the symbols at the time of the `shl_load' call.
|
| -
|
| - There are times, however, when you may wish to not automatically load
|
| -symbol definitions from shared libraries, such as when they are
|
| -particularly large or there are many of them.
|
| -
|
| - To control the automatic loading of shared library symbols, use the
|
| -commands:
|
| -
|
| -`set auto-solib-add MODE'
|
| - If MODE is `on', symbols from all shared object libraries will be
|
| - loaded automatically when the inferior begins execution, you
|
| - attach to an independently started inferior, or when the dynamic
|
| - linker informs GDB that a new library has been loaded. If MODE is
|
| - `off', symbols must be loaded manually, using the `sharedlibrary'
|
| - command. The default value is `on'.
|
| -
|
| - If your program uses lots of shared libraries with debug info that
|
| - takes large amounts of memory, you can decrease the GDB memory
|
| - footprint by preventing it from automatically loading the symbols
|
| - from shared libraries. To that end, type `set auto-solib-add off'
|
| - before running the inferior, then load each library whose debug
|
| - symbols you do need with `sharedlibrary REGEXP', where REGEXP is a
|
| - regular expression that matches the libraries whose symbols you
|
| - want to be loaded.
|
| -
|
| -`show auto-solib-add'
|
| - Display the current autoloading mode.
|
| -
|
| - To explicitly load shared library symbols, use the `sharedlibrary'
|
| -command:
|
| -
|
| -`info share REGEX'
|
| -`info sharedlibrary REGEX'
|
| - Print the names of the shared libraries which are currently loaded
|
| - that match REGEX. If REGEX is omitted then print all shared
|
| - libraries that are loaded.
|
| -
|
| -`sharedlibrary REGEX'
|
| -`share REGEX'
|
| - Load shared object library symbols for files matching a Unix
|
| - regular expression. As with files loaded automatically, it only
|
| - loads shared libraries required by your program for a core file or
|
| - after typing `run'. If REGEX is omitted all shared libraries
|
| - required by your program are loaded.
|
| -
|
| -`nosharedlibrary'
|
| - Unload all shared object library symbols. This discards all
|
| - symbols that have been loaded from all shared libraries. Symbols
|
| - from shared libraries that were loaded by explicit user requests
|
| - are not discarded.
|
| -
|
| - Sometimes you may wish that GDB stops and gives you control when any
|
| -of shared library events happen. The best way to do this is to use
|
| -`catch load' and `catch unload' (*note Set Catchpoints::).
|
| -
|
| - GDB also supports the the `set stop-on-solib-events' command for
|
| -this. This command exists for historical reasons. It is less useful
|
| -than setting a catchpoint, because it does not allow for conditions or
|
| -commands as a catchpoint does.
|
| -
|
| -`set stop-on-solib-events'
|
| - This command controls whether GDB should give you control when the
|
| - dynamic linker notifies it about some shared library event. The
|
| - most common event of interest is loading or unloading of a new
|
| - shared library.
|
| -
|
| -`show stop-on-solib-events'
|
| - Show whether GDB stops and gives you control when shared library
|
| - events happen.
|
| -
|
| - Shared libraries are also supported in many cross or remote debugging
|
| -configurations. GDB needs to have access to the target's libraries;
|
| -this can be accomplished either by providing copies of the libraries on
|
| -the host system, or by asking GDB to automatically retrieve the
|
| -libraries from the target. If copies of the target libraries are
|
| -provided, they need to be the same as the target libraries, although the
|
| -copies on the target can be stripped as long as the copies on the host
|
| -are not.
|
| -
|
| - For remote debugging, you need to tell GDB where the target
|
| -libraries are, so that it can load the correct copies--otherwise, it
|
| -may try to load the host's libraries. GDB has two variables to specify
|
| -the search directories for target libraries.
|
| -
|
| -`set sysroot PATH'
|
| - Use PATH as the system root for the program being debugged. Any
|
| - absolute shared library paths will be prefixed with PATH; many
|
| - runtime loaders store the absolute paths to the shared library in
|
| - the target program's memory. If you use `set sysroot' to find
|
| - shared libraries, they need to be laid out in the same way that
|
| - they are on the target, with e.g. a `/lib' and `/usr/lib' hierarchy
|
| - under PATH.
|
| -
|
| - If PATH starts with the sequence `remote:', GDB will retrieve the
|
| - target libraries from the remote system. This is only supported
|
| - when using a remote target that supports the `remote get' command
|
| - (*note Sending files to a remote system: File Transfer.). The
|
| - part of PATH following the initial `remote:' (if present) is used
|
| - as system root prefix on the remote file system. (1)
|
| -
|
| - For targets with an MS-DOS based filesystem, such as MS-Windows and
|
| - SymbianOS, GDB tries prefixing a few variants of the target
|
| - absolute file name with PATH. But first, on Unix hosts, GDB
|
| - converts all backslash directory separators into forward slashes,
|
| - because the backslash is not a directory separator on Unix:
|
| -
|
| - c:\foo\bar.dll => c:/foo/bar.dll
|
| -
|
| - Then, GDB attempts prefixing the target file name with PATH, and
|
| - looks for the resulting file name in the host file system:
|
| -
|
| - c:/foo/bar.dll => /path/to/sysroot/c:/foo/bar.dll
|
| -
|
| - If that does not find the shared library, GDB tries removing the
|
| - `:' character from the drive spec, both for convenience, and, for
|
| - the case of the host file system not supporting file names with
|
| - colons:
|
| -
|
| - c:/foo/bar.dll => /path/to/sysroot/c/foo/bar.dll
|
| -
|
| - This makes it possible to have a system root that mirrors a target
|
| - with more than one drive. E.g., you may want to setup your local
|
| - copies of the target system shared libraries like so (note `c' vs
|
| - `z'):
|
| -
|
| - `/path/to/sysroot/c/sys/bin/foo.dll'
|
| - `/path/to/sysroot/c/sys/bin/bar.dll'
|
| - `/path/to/sysroot/z/sys/bin/bar.dll'
|
| -
|
| - and point the system root at `/path/to/sysroot', so that GDB can
|
| - find the correct copies of both `c:\sys\bin\foo.dll', and
|
| - `z:\sys\bin\bar.dll'.
|
| -
|
| - If that still does not find the shared library, GDB tries removing
|
| - the whole drive spec from the target file name:
|
| -
|
| - c:/foo/bar.dll => /path/to/sysroot/foo/bar.dll
|
| -
|
| - This last lookup makes it possible to not care about the drive
|
| - name, if you don't want or need to.
|
| -
|
| - The `set solib-absolute-prefix' command is an alias for `set
|
| - sysroot'.
|
| -
|
| - You can set the default system root by using the configure-time
|
| - `--with-sysroot' option. If the system root is inside GDB's
|
| - configured binary prefix (set with `--prefix' or `--exec-prefix'),
|
| - then the default system root will be updated automatically if the
|
| - installed GDB is moved to a new location.
|
| -
|
| -`show sysroot'
|
| - Display the current shared library prefix.
|
| -
|
| -`set solib-search-path PATH'
|
| - If this variable is set, PATH is a colon-separated list of
|
| - directories to search for shared libraries. `solib-search-path'
|
| - is used after `sysroot' fails to locate the library, or if the
|
| - path to the library is relative instead of absolute. If you want
|
| - to use `solib-search-path' instead of `sysroot', be sure to set
|
| - `sysroot' to a nonexistent directory to prevent GDB from finding
|
| - your host's libraries. `sysroot' is preferred; setting it to a
|
| - nonexistent directory may interfere with automatic loading of
|
| - shared library symbols.
|
| -
|
| -`show solib-search-path'
|
| - Display the current shared library search path.
|
| -
|
| -`set target-file-system-kind KIND'
|
| - Set assumed file system kind for target reported file names.
|
| -
|
| - Shared library file names as reported by the target system may not
|
| - make sense as is on the system GDB is running on. For example,
|
| - when remote debugging a target that has MS-DOS based file system
|
| - semantics, from a Unix host, the target may be reporting to GDB a
|
| - list of loaded shared libraries with file names such as
|
| - `c:\Windows\kernel32.dll'. On Unix hosts, there's no concept of
|
| - drive letters, so the `c:\' prefix is not normally understood as
|
| - indicating an absolute file name, and neither is the backslash
|
| - normally considered a directory separator character. In that case,
|
| - the native file system would interpret this whole absolute file
|
| - name as a relative file name with no directory components. This
|
| - would make it impossible to point GDB at a copy of the remote
|
| - target's shared libraries on the host using `set sysroot', and
|
| - impractical with `set solib-search-path'. Setting
|
| - `target-file-system-kind' to `dos-based' tells GDB to interpret
|
| - such file names similarly to how the target would, and to map them
|
| - to file names valid on GDB's native file system semantics. The
|
| - value of KIND can be `"auto"', in addition to one of the supported
|
| - file system kinds. In that case, GDB tries to determine the
|
| - appropriate file system variant based on the current target's
|
| - operating system (*note Configuring the Current ABI: ABI.). The
|
| - supported file system settings are:
|
| -
|
| - `unix'
|
| - Instruct GDB to assume the target file system is of Unix
|
| - kind. Only file names starting the forward slash (`/')
|
| - character are considered absolute, and the directory
|
| - separator character is also the forward slash.
|
| -
|
| - `dos-based'
|
| - Instruct GDB to assume the target file system is DOS based.
|
| - File names starting with either a forward slash, or a drive
|
| - letter followed by a colon (e.g., `c:'), are considered
|
| - absolute, and both the slash (`/') and the backslash (`\\')
|
| - characters are considered directory separators.
|
| -
|
| - `auto'
|
| - Instruct GDB to use the file system kind associated with the
|
| - target operating system (*note Configuring the Current ABI:
|
| - ABI.). This is the default.
|
| -
|
| - When processing file names provided by the user, GDB frequently
|
| -needs to compare them to the file names recorded in the program's debug
|
| -info. Normally, GDB compares just the "base names" of the files as
|
| -strings, which is reasonably fast even for very large programs. (The
|
| -base name of a file is the last portion of its name, after stripping
|
| -all the leading directories.) This shortcut in comparison is based
|
| -upon the assumption that files cannot have more than one base name.
|
| -This is usually true, but references to files that use symlinks or
|
| -similar filesystem facilities violate that assumption. If your program
|
| -records files using such facilities, or if you provide file names to
|
| -GDB using symlinks etc., you can set `basenames-may-differ' to `true'
|
| -to instruct GDB to completely canonicalize each pair of file names it
|
| -needs to compare. This will make file-name comparisons accurate, but
|
| -at a price of a significant slowdown.
|
| -
|
| -`set basenames-may-differ'
|
| - Set whether a source file may have multiple base names.
|
| -
|
| -`show basenames-may-differ'
|
| - Show whether a source file may have multiple base names.
|
| -
|
| - ---------- Footnotes ----------
|
| -
|
| - (1) If you want to specify a local system root using a directory
|
| -that happens to be named `remote:', you need to use some equivalent
|
| -variant of the name like `./remote:'.
|
| -
|
| -
|
| -File: gdb.info, Node: Separate Debug Files, Next: Index Files, Prev: Files, Up: GDB Files
|
| -
|
| -18.2 Debugging Information in Separate Files
|
| -============================================
|
| -
|
| -GDB allows you to put a program's debugging information in a file
|
| -separate from the executable itself, in a way that allows GDB to find
|
| -and load the debugging information automatically. Since debugging
|
| -information can be very large--sometimes larger than the executable
|
| -code itself--some systems distribute debugging information for their
|
| -executables in separate files, which users can install only when they
|
| -need to debug a problem.
|
| -
|
| - GDB supports two ways of specifying the separate debug info file:
|
| -
|
| - * The executable contains a "debug link" that specifies the name of
|
| - the separate debug info file. The separate debug file's name is
|
| - usually `EXECUTABLE.debug', where EXECUTABLE is the name of the
|
| - corresponding executable file without leading directories (e.g.,
|
| - `ls.debug' for `/usr/bin/ls'). In addition, the debug link
|
| - specifies a 32-bit "Cyclic Redundancy Check" (CRC) checksum for
|
| - the debug file, which GDB uses to validate that the executable and
|
| - the debug file came from the same build.
|
| -
|
| - * The executable contains a "build ID", a unique bit string that is
|
| - also present in the corresponding debug info file. (This is
|
| - supported only on some operating systems, notably those which use
|
| - the ELF format for binary files and the GNU Binutils.) For more
|
| - details about this feature, see the description of the `--build-id'
|
| - command-line option in *Note Command Line Options:
|
| - (ld.info)Options. The debug info file's name is not specified
|
| - explicitly by the build ID, but can be computed from the build ID,
|
| - see below.
|
| -
|
| - Depending on the way the debug info file is specified, GDB uses two
|
| -different methods of looking for the debug file:
|
| -
|
| - * For the "debug link" method, GDB looks up the named file in the
|
| - directory of the executable file, then in a subdirectory of that
|
| - directory named `.debug', and finally under each one of the global
|
| - debug directories, in a subdirectory whose name is identical to
|
| - the leading directories of the executable's absolute file name.
|
| -
|
| - * For the "build ID" method, GDB looks in the `.build-id'
|
| - subdirectory of each one of the global debug directories for a
|
| - file named `NN/NNNNNNNN.debug', where NN are the first 2 hex
|
| - characters of the build ID bit string, and NNNNNNNN are the rest
|
| - of the bit string. (Real build ID strings are 32 or more hex
|
| - characters, not 10.)
|
| -
|
| - So, for example, suppose you ask GDB to debug `/usr/bin/ls', which
|
| -has a debug link that specifies the file `ls.debug', and a build ID
|
| -whose value in hex is `abcdef1234'. If the list of the global debug
|
| -directories includes `/usr/lib/debug', then GDB will look for the
|
| -following debug information files, in the indicated order:
|
| -
|
| - - `/usr/lib/debug/.build-id/ab/cdef1234.debug'
|
| -
|
| - - `/usr/bin/ls.debug'
|
| -
|
| - - `/usr/bin/.debug/ls.debug'
|
| -
|
| - - `/usr/lib/debug/usr/bin/ls.debug'.
|
| -
|
| - Global debugging info directories default to what is set by GDB
|
| -configure option `--with-separate-debug-dir'. During GDB run you can
|
| -also set the global debugging info directories, and view the list GDB
|
| -is currently using.
|
| -
|
| -`set debug-file-directory DIRECTORIES'
|
| - Set the directories which GDB searches for separate debugging
|
| - information files to DIRECTORY. Multiple path components can be
|
| - set concatenating them by a path separator.
|
| -
|
| -`show debug-file-directory'
|
| - Show the directories GDB searches for separate debugging
|
| - information files.
|
| -
|
| -
|
| - A debug link is a special section of the executable file named
|
| -`.gnu_debuglink'. The section must contain:
|
| -
|
| - * A filename, with any leading directory components removed,
|
| - followed by a zero byte,
|
| -
|
| - * zero to three bytes of padding, as needed to reach the next
|
| - four-byte boundary within the section, and
|
| -
|
| - * a four-byte CRC checksum, stored in the same endianness used for
|
| - the executable file itself. The checksum is computed on the
|
| - debugging information file's full contents by the function given
|
| - below, passing zero as the CRC argument.
|
| -
|
| - Any executable file format can carry a debug link, as long as it can
|
| -contain a section named `.gnu_debuglink' with the contents described
|
| -above.
|
| -
|
| - The build ID is a special section in the executable file (and in
|
| -other ELF binary files that GDB may consider). This section is often
|
| -named `.note.gnu.build-id', but that name is not mandatory. It
|
| -contains unique identification for the built files--the ID remains the
|
| -same across multiple builds of the same build tree. The default
|
| -algorithm SHA1 produces 160 bits (40 hexadecimal characters) of the
|
| -content for the build ID string. The same section with an identical
|
| -value is present in the original built binary with symbols, in its
|
| -stripped variant, and in the separate debugging information file.
|
| -
|
| - The debugging information file itself should be an ordinary
|
| -executable, containing a full set of linker symbols, sections, and
|
| -debugging information. The sections of the debugging information file
|
| -should have the same names, addresses, and sizes as the original file,
|
| -but they need not contain any data--much like a `.bss' section in an
|
| -ordinary executable.
|
| -
|
| - The GNU binary utilities (Binutils) package includes the `objcopy'
|
| -utility that can produce the separated executable / debugging
|
| -information file pairs using the following commands:
|
| -
|
| - objcopy --only-keep-debug foo foo.debug
|
| - strip -g foo
|
| -
|
| -These commands remove the debugging information from the executable
|
| -file `foo' and place it in the file `foo.debug'. You can use the
|
| -first, second or both methods to link the two files:
|
| -
|
| - * The debug link method needs the following additional command to
|
| - also leave behind a debug link in `foo':
|
| -
|
| - objcopy --add-gnu-debuglink=foo.debug foo
|
| -
|
| - Ulrich Drepper's `elfutils' package, starting with version 0.53,
|
| - contains a version of the `strip' command such that the command
|
| - `strip foo -f foo.debug' has the same functionality as the two
|
| - `objcopy' commands and the `ln -s' command above, together.
|
| -
|
| - * Build ID gets embedded into the main executable using `ld
|
| - --build-id' or the GCC counterpart `gcc -Wl,--build-id'. Build ID
|
| - support plus compatibility fixes for debug files separation are
|
| - present in GNU binary utilities (Binutils) package since version
|
| - 2.18.
|
| -
|
| -The CRC used in `.gnu_debuglink' is the CRC-32 defined in IEEE 802.3
|
| -using the polynomial:
|
| -
|
| - x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11
|
| - + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
|
| -
|
| - The function is computed byte at a time, taking the least
|
| -significant bit of each byte first. The initial pattern `0xffffffff'
|
| -is used, to ensure leading zeros affect the CRC and the final result is
|
| -inverted to ensure trailing zeros also affect the CRC.
|
| -
|
| - _Note:_ This is the same CRC polynomial as used in handling the
|
| -"Remote Serial Protocol" `qCRC' packet (*note GDB Remote Serial
|
| -Protocol: Remote Protocol.). However in the case of the Remote Serial
|
| -Protocol, the CRC is computed _most_ significant bit first, and the
|
| -result is not inverted, so trailing zeros have no effect on the CRC
|
| -value.
|
| -
|
| - To complete the description, we show below the code of the function
|
| -which produces the CRC used in `.gnu_debuglink'. Inverting the
|
| -initially supplied `crc' argument means that an initial call to this
|
| -function passing in zero will start computing the CRC using
|
| -`0xffffffff'.
|
| -
|
| - unsigned long
|
| - gnu_debuglink_crc32 (unsigned long crc,
|
| - unsigned char *buf, size_t len)
|
| - {
|
| - static const unsigned long crc32_table[256] =
|
| - {
|
| - 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419,
|
| - 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4,
|
| - 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07,
|
| - 0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
|
| - 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856,
|
| - 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
|
| - 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4,
|
| - 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
|
| - 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3,
|
| - 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a,
|
| - 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599,
|
| - 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
|
| - 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190,
|
| - 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f,
|
| - 0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e,
|
| - 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
|
| - 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed,
|
| - 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
|
| - 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3,
|
| - 0xfbd44c65, 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
|
| - 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a,
|
| - 0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5,
|
| - 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa, 0xbe0b1010,
|
| - 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
|
| - 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17,
|
| - 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6,
|
| - 0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615,
|
| - 0x73dc1683, 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
|
| - 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 0xf00f9344,
|
| - 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
|
| - 0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a,
|
| - 0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
|
| - 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1,
|
| - 0xa6bc5767, 0x3fb506dd, 0x48b2364b, 0xd80d2bda, 0xaf0a1b4c,
|
| - 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef,
|
| - 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
|
| - 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe,
|
| - 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31,
|
| - 0x2cd99e8b, 0x5bdeae1d, 0x9b64c2b0, 0xec63f226, 0x756aa39c,
|
| - 0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
|
| - 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b,
|
| - 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
|
| - 0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1,
|
| - 0x18b74777, 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
|
| - 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 0xa00ae278,
|
| - 0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7,
|
| - 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc, 0x40df0b66,
|
| - 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
|
| - 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605,
|
| - 0xcdd70693, 0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8,
|
| - 0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b,
|
| - 0x2d02ef8d
|
| - };
|
| - unsigned char *end;
|
| -
|
| - crc = ~crc & 0xffffffff;
|
| - for (end = buf + len; buf < end; ++buf)
|
| - crc = crc32_table[(crc ^ *buf) & 0xff] ^ (crc >> 8);
|
| - return ~crc & 0xffffffff;
|
| - }
|
| -
|
| -This computation does not apply to the "build ID" method.
|
| -
|
| -
|
| -File: gdb.info, Node: Index Files, Next: Symbol Errors, Prev: Separate Debug Files, Up: GDB Files
|
| -
|
| -18.3 Index Files Speed Up GDB
|
| -=============================
|
| -
|
| -When GDB finds a symbol file, it scans the symbols in the file in order
|
| -to construct an internal symbol table. This lets most GDB operations
|
| -work quickly--at the cost of a delay early on. For large programs,
|
| -this delay can be quite lengthy, so GDB provides a way to build an
|
| -index, which speeds up startup.
|
| -
|
| - The index is stored as a section in the symbol file. GDB can write
|
| -the index to a file, then you can put it into the symbol file using
|
| -`objcopy'.
|
| -
|
| - To create an index file, use the `save gdb-index' command:
|
| -
|
| -`save gdb-index DIRECTORY'
|
| - Create an index file for each symbol file currently known by GDB.
|
| - Each file is named after its corresponding symbol file, with
|
| - `.gdb-index' appended, and is written into the given DIRECTORY.
|
| -
|
| - Once you have created an index file you can merge it into your symbol
|
| -file, here named `symfile', using `objcopy':
|
| -
|
| - $ objcopy --add-section .gdb_index=symfile.gdb-index \
|
| - --set-section-flags .gdb_index=readonly symfile symfile
|
| -
|
| - GDB will normally ignore older versions of `.gdb_index' sections
|
| -that have been deprecated. Usually they are deprecated because they
|
| -are missing a new feature or have performance issues. To tell GDB to
|
| -use a deprecated index section anyway specify `set
|
| -use-deprecated-index-sections on'. The default is `off'. This can
|
| -speed up startup, but may result in some functionality being lost.
|
| -*Note Index Section Format::.
|
| -
|
| - _Warning:_ Setting `use-deprecated-index-sections' to `on' must be
|
| -done before gdb reads the file. The following will not work:
|
| -
|
| - $ gdb -ex "set use-deprecated-index-sections on" <program>
|
| -
|
| - Instead you must do, for example,
|
| -
|
| - $ gdb -iex "set use-deprecated-index-sections on" <program>
|
| -
|
| - There are currently some limitation on indices. They only work when
|
| -for DWARF debugging information, not stabs. And, they do not currently
|
| -work for programs using Ada.
|
| -
|
|
|
Chromium Code Reviews
Issue 124383005:
GDB 7.6.50 (Closed)
Base URL: http://git.chromium.org/native_client/nacl-gdb.git@upstream