Debugging with gdb
`
`The gnu Source-Level Debugger
`
`Ninth Edition, for gdb version 7.0.50.20100218-cvs
`
`(Sourcery G++ Lite 2010q1-188)
`
`Richard Stallman, Roland Pesch, Stan Shebs, et al.
`
`
`Exhibit Page 1
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375
`
`

`
`(Send bugs and comments on gdb to
`https://support.codesourcery.com/GNUToolchain/.)
`
`Debugging with gdb
`TEXinfo 2008-04-18.10
`
`Published by the Free Software Foundation
`51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
`ISBN 1-882114-77-9
`
`Copyright c(cid:13) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
`2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
`Permission is granted to copy, distribute and/or modify this document under the terms
`of the GNU Free Documentation License, Version 1.1 or any later version published by
`the Free Software Foundation; with the Invariant Sections being “Free Software” and “Free
`Software Needs Free Documentation”, with the Front-Cover Texts being “A GNU Manual,”
`and with the Back-Cover Texts as in (a) below.
`(a) The FSF’s Back-Cover Text is: “You are free to copy and modify this GNU Man-
`ual. Buying copies from GNU Press supports the FSF in developing GNU and promoting
`software freedom.”
`
`
`Exhibit Page 2
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375
`
`

`
`Chapter 8: Examining the Stack
`
`77
`
`8 Examining the Stack
`
`When your program has stopped, the first thing you need to know is where it stopped and
`how it got there.
`Each time your program performs a function call, information about the call is generated.
`That information includes the location of the call in your program, the arguments of the
`call, and the local variables of the function being called. The information is saved in a block
`of data called a stack frame. The stack frames are allocated in a region of memory called
`the call stack.
`When your program stops, the gdb commands for examining the stack allow you to see
`all of this information.
`One of the stack frames is selected by gdb and many gdb commands refer implicitly
`to the selected frame. In particular, whenever you ask gdb for the value of a variable in
`your program, the value is found in the selected frame. There are special gdb commands to
`select whichever frame you are interested in. See Section 8.3 [Selecting a Frame], page 80.
`When your program stops, gdb automatically selects the currently executing frame and
`describes it briefly, similar to the frame command (see Section 8.4 [Information about a
`Frame], page 81).
`
`8.1 Stack Frames
`The call stack is divided up into contiguous pieces called stack frames, or frames for short;
`each frame is the data associated with one call to one function. The frame contains the
`arguments given to the function, the function’s local variables, and the address at which
`the function is executing.
`When your program is started, the stack has only one frame, that of the function main.
`This is called the initial frame or the outermost frame. Each time a function is called, a
`new frame is made. Each time a function returns, the frame for that function invocation
`is eliminated. If a function is recursive, there can be many frames for the same function.
`The frame for the function in which execution is actually occurring is called the innermost
`frame. This is the most recently created of all the stack frames that still exist.
`Inside your program, stack frames are identified by their addresses. A stack frame
`consists of many bytes, each of which has its own address; each kind of computer has a con-
`vention for choosing one byte whose address serves as the address of the frame. Usually this
`address is kept in a register called the frame pointer register (see Section 10.11 [Registers],
`page 110) while execution is going on in that frame.
`gdb assigns numbers to all existing stack frames, starting with zero for the innermost
`frame, one for the frame that called it, and so on upward. These numbers do not really
`exist in your program; they are assigned by gdb to give you a way of designating stack
`frames in gdb commands.
`Some compilers provide a way to compile functions so that they operate without stack
`frames. (For example, the gcc option
`‘-fomit-frame-pointer’
`generates functions without a frame.) This is occasionally done with heavily used li-
`brary functions to save the frame setup time. gdb has limited facilities for dealing with
`
`
`Exhibit Page 3
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375
`
`

`
`78
`
`Debugging with gdb
`
`these function invocations. If the innermost function invocation has no stack frame, gdb
`nevertheless regards it as though it had a separate frame, which is numbered zero as usual,
`allowing correct tracing of the function call chain. However, gdb has no provision for
`frameless functions elsewhere in the stack.
`
`frame args
`
`The frame command allows you to move from one stack frame to another, and
`to print the stack frame you select. args may be either the address of the frame
`or the stack frame number. Without an argument, frame prints the current
`stack frame.
`
`select-frame
`The select-frame command allows you to move from one stack frame to an-
`other without printing the frame. This is the silent version of frame.
`
`8.2 Backtraces
`A backtrace is a summary of how your program got where it is. It shows one line per frame,
`for many frames, starting with the currently executing frame (frame zero), followed by its
`caller (frame one), and on up the stack.
`
`backtrace
`bt
`
`Print a backtrace of the entire stack: one line per frame for all frames in the
`stack.
`You can stop the backtrace at any time by typing the system interrupt charac-
`ter, normally Ctrl-c.
`
`backtrace n
`Similar, but print only the innermost n frames.
`bt n
`
`backtrace -n
`Similar, but print only the outermost n frames.
`bt -n
`
`backtrace full
`bt full
`bt full n
`bt full -n
`
`Print the values of the local variables also. n specifies the number of frames to
`print, as described above.
`The names where and info stack (abbreviated info s) are additional aliases for
`backtrace.
`In a multi-threaded program, gdb by default shows the backtrace only for the current
`thread. To display the backtrace for several or all of the threads, use the command thread
`apply (see Section 4.10 [Threads], page 35). For example, if you type thread apply all
`backtrace, gdb will display the backtrace for all the threads; this is handy when you debug
`a core dump of a multi-threaded program.
`Each line in the backtrace shows the frame number and the function name. The program
`counter value is also shown—unless you use set print address off. The backtrace also
`shows the source file name and line number, as well as the arguments to the function. The
`program counter value is omitted if it is at the beginning of the code for that line number.
`
`
`Exhibit Page 4
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375
`
`

`
`Chapter 8: Examining the Stack
`
`79
`
`Here is an example of a backtrace. It was made with the command ‘bt 3’, so it shows
`the innermost three frames.
`#0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8)
`at builtin.c:993
`#1 0x6e38 in expand_macro (sym=0x2b600, data=...) at macro.c:242
`#2 0x6840 in expand_token (obs=0x0, t=177664, td=0xf7fffb08)
`at macro.c:71
`(More stack frames follow...)
`The display for frame zero does not begin with a program counter value, indicating that
`your program has stopped at the beginning of the code for line 993 of builtin.c.
`The value of parameter data in frame 1 has been replaced by .... By default, gdb prints
`the value of a parameter only if it is a scalar (integer, pointer, enumeration, etc). See
`command set print frame-arguments in Section 10.8 [Print Settings], page 102 for more
`details on how to configure the way function parameter values are printed.
`If your program was compiled with optimizations, some compilers will optimize away
`arguments passed to functions if those arguments are never used after the call. Such opti-
`mizations generate code that passes arguments through registers, but doesn’t store those
`arguments in the stack frame. gdb has no way of displaying such arguments in stack frames
`other than the innermost one. Here’s what such a backtrace might look like:
`#0 m4_traceon (obs=0x24eb0, argc=1, argv=0x2b8c8)
`at builtin.c:993
`#1 0x6e38 in expand_macro (sym=<value optimized out>) at macro.c:242
`#2 0x6840 in expand_token (obs=0x0, t=<value optimized out>, td=0xf7fffb08)
`at macro.c:71
`(More stack frames follow...)
`The values of arguments that were not saved in their stack frames are shown as ‘<value
`optimized out>’.
`If you need to display the values of such optimized-out arguments, either deduce that
`from other variables whose values depend on the one you are interested in, or recompile
`without optimizations.
`Most programs have a standard user entry point—a place where system libraries and
`startup code transition into user code. For C this is main1. When gdb finds the entry
`function in a backtrace it will terminate the backtrace, to avoid tracing into highly system-
`specific (and generally uninteresting) code.
`If you need to examine the startup code, or limit the number of levels in a backtrace,
`you can change this behavior:
`
`set backtrace past-main
`set backtrace past-main on
`Backtraces will continue past the user entry point.
`
`set backtrace past-main off
`Backtraces will stop when they encounter the user entry point. This is the
`default.
`
`show backtrace past-main
`Display the current user entry point backtrace policy.
`
`1 Note that embedded programs (the so-called “free-standing” environment) are not required to have a
`main function as the entry point. They could even have multiple entry points.
`
`
`Exhibit Page 5
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375
`
`

`
`80
`
`Debugging with gdb
`
`set backtrace past-entry
`set backtrace past-entry on
`Backtraces will continue past the internal entry point of an application. This
`entry point is encoded by the linker when the application is built, and is likely
`before the user entry point main (or equivalent) is called.
`
`set backtrace past-entry off
`Backtraces will stop when they encounter the internal entry point of an appli-
`cation. This is the default.
`
`show backtrace past-entry
`Display the current internal entry point backtrace policy.
`
`set backtrace limit n
`set backtrace limit 0
`Limit the backtrace to n levels. A value of zero means unlimited.
`
`show backtrace limit
`Display the current limit on backtrace levels.
`
`8.3 Selecting a Frame
`Most commands for examining the stack and other data in your program work on whichever
`stack frame is selected at the moment. Here are the commands for selecting a stack frame;
`all of them finish by printing a brief description of the stack frame just selected.
`
`frame n
`f n
`
`frame addr
`f addr
`
`up n
`
`down n
`
`Select frame number n. Recall that frame zero is the innermost (currently
`executing) frame, frame one is the frame that called the innermost one, and so
`on. The highest-numbered frame is the one for main.
`
`Select the frame at address addr. This is useful mainly if the chaining of stack
`frames has been damaged by a bug, making it impossible for gdb to assign
`numbers properly to all frames.
`In addition, this can be useful when your
`program has multiple stacks and switches between them.
`On the MIPS and Alpha architectures, frame needs two addresses to select an
`arbitrary frame: a stack pointer and a program counter.
`
`Move n frames up the stack. For positive numbers n, this advances toward the
`outermost frame, to higher frame numbers, to frames that have existed longer.
`n defaults to one.
`
`Move n frames down the stack. For positive numbers n, this advances toward
`the innermost frame, to lower frame numbers, to frames that were created more
`recently. n defaults to one. You may abbreviate down as do.
`
`All of these commands end by printing two lines of output describing the frame. The
`first line shows the frame number, the function name, the arguments, and the source file
`and line number of execution in that frame. The second line shows the text of that source
`line.
`
`
`Exhibit Page 6
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375
`
`

`
`Chapter 8: Examining the Stack
`
`81
`
`For example:
`(gdb) up
`#1 0x22f0 in main (argc=1, argv=0xf7fffbf4, env=0xf7fffbfc)
`at env.c:10
`
`10
`read_input_file (argv[i]);
`After such a printout, the list command with no arguments prints ten lines centered on
`the point of execution in the frame. You can also edit the program at the point of execution
`with your favorite editing program by typing edit. See Section 9.1 [Printing Source Lines],
`page 83, for details.
`
`up-silently n
`down-silently n
`These two commands are variants of up and down, respectively; they differ in
`that they do their work silently, without causing display of the new frame. They
`are intended primarily for use in gdb command scripts, where the output might
`be unnecessary and distracting.
`
`8.4 Information About a Frame
`There are several other commands to print information about the selected stack frame.
`
`frame
`f
`
`info frame
`info f
`
`When used without any argument, this command does not change which frame
`is selected, but prints a brief description of the currently selected stack frame.
`It can be abbreviated f. With an argument, this command is used to select a
`stack frame. See Section 8.3 [Selecting a Frame], page 80.
`
`This command prints a verbose description of the selected stack frame, includ-
`ing:
`• the address of the frame
`• the address of the next frame down (called by this frame)
`• the address of the next frame up (caller of this frame)
`• the language in which the source code corresponding to this frame is written
`• the address of the frame’s arguments
`• the address of the frame’s local variables
`• the program counter saved in it (the address of execution in the caller
`frame)
`• which registers were saved in the frame
`The verbose description is useful when something has gone wrong that has made
`the stack format fail to fit the usual conventions.
`
`info frame addr
`info f addr
`Print a verbose description of the frame at address addr, without selecting that
`frame. The selected frame remains unchanged by this command. This requires
`the same kind of address (more than one for some architectures) that you specify
`in the frame command. See Section 8.3 [Selecting a Frame], page 80.
`
`
`Exhibit Page 7
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375
`
`

`
`82
`
`Debugging with gdb
`
`info args Print the arguments of the selected frame, each on a separate line.
`
`info locals
`Print the local variables of the selected frame, each on a separate line. These
`are all variables (declared either static or automatic) accessible at the point of
`execution of the selected frame.
`
`info catch
`
`Print a list of all the exception handlers that are active in the current stack
`frame at the current point of execution. To see other exception handlers, visit
`the associated frame (using the up, down, or frame commands); then type info
`catch. See Section 5.1.3 [Setting Catchpoints], page 51.
`
`
`Exhibit Page 8
`
`Columbia Ex. 2012
`Symantec v. Columbia
`IPR2015-00375