Lines Matching full:program
124 going on "inside" another program while it executes--or what another
125 program was doing at the moment it crashed.
130 * Start your program, specifying anything that might affect its
133 * Make your program stop on specified conditions.
135 * Examine what has happened, when your program has stopped.
137 * Change things in your program, so you can experiment with
176 program--but every person getting a copy also gets with it the freedom
220 accompany every copy of the program, both on-line and on paper.
225 accurate and clear documentation for the modified program. A manual
227 changed version of the program is not really available to our community.
512 program runs as usual:
515 Starting program: /work/Editorial/gdb/gnu/m4/m4
649 Program exited normally.
651 The message `Program exited normally.' is from GDB; it indicates `m4'
682 Invoke GDB by running the program `gdb'. Once started, GDB reads
693 executable program:
695 gdb PROGRAM
697 You can also start with both an executable program and a core file
700 gdb PROGRAM CORE
705 gdb PROGRAM 1234
857 to download and run a program on another computer; in order to
860 Program exited normally.
862 (which is ordinarily issued whenever a program running under GDB
892 `-batch-silent', when GDB is being used as a remote program loader
919 displayed (which includes each time your program stops). This
922 colons, and a newline. The Emacs-to-GDB interface program uses
960 Run using DEVICE for your program's standard input and output.
967 Interface can be enabled by invoking the program `gdbtui'. Do not
973 program or device. This option is meant to be set by programs
1029 and another, specific to the program you are debugging, in the
1032 6. If the command line specified a program to debug, or a process to
1034 provided for the program or for its loaded shared libraries.
1118 Execute the `make' program with the specified arguments. This is
1226 commands, GDB subcommands, and the names of symbols in your program.
1253 displays all the function names in your program that begin with those
1362 breakpoints -- Making program stop at certain points
1367 running -- Running the program
1371 tracepoints -- Tracing of program execution without
1372 stopping the program
1393 about the program being debugged
1437 `show' to inquire about the state of your program, or the state of GDB
1445 program. For example, you can show the arguments passed to a
1496 When you run a program under GDB, you must first generate debugging
1501 program's input and output, debug an already running process, or kill a
1507 * Starting:: Starting your program
1508 * Arguments:: Your program's arguments
1509 * Environment:: Your program's environment
1511 * Working Directory:: Your program's working directory
1512 * Input/Output:: Your program's input and output
1527 In order to debug a program effectively, you need to generate debugging
1544 _always_ use `-g' whenever you compile a program. You may think your
1545 program is correct, but there is no sense in pushing your luck. For
1566 4.2 Starting your Program
1571 Use the `run' command to start your program under GDB. You must
1572 first specify the program name (except on VxWorks) with an
1578 If you are running your program in an execution environment that
1580 process run your program. In some environments without processes,
1581 `run' jumps to the start of your program. Other targets, like
1588 then use `continue' to run your program. You may need `load' first
1591 The execution of a program is affected by certain information it
1593 information, which you must do _before_ starting your program. (You
1594 can change it after starting your program, but such changes only affect
1595 your program the next time you start it.) This information may be
1599 Specify the arguments to give your program as the arguments of the
1605 Your Program's Arguments: Arguments.
1608 Your program normally inherits its environment from GDB, but you
1610 to change parts of the environment that affect your program.
1611 *Note Your Program's Environment: Environment.
1614 Your program inherits its working directory from GDB. You can set
1616 Your Program's Working Directory: Working Directory.
1619 Your program normally uses the same device for standard input and
1622 a different device for your program. *Note Your Program's Input
1626 pipes to pass the output of the program you are debugging to
1627 another program; if you attempt this, GDB is likely to wind up
1628 debugging the wrong program.
1630 When you issue the `run' command, your program begins to execute
1632 of how to arrange for your program to stop. Once your program has
1633 stopped, you may call functions in your program, using the `print' or
1646 the execution of the program and to stop at the beginning of the
1655 depends on the languages used to write your program. In C++, for
1661 Specify the arguments to give to your program as arguments to the
1667 It is sometimes necessary to debug the program during elaboration.
1669 of your program too late, as the program would have already
1672 program.
1678 launch programs for debugging. GDB starts your program with a
1679 shell command of the form `exec WRAPPER PROGRAM'. Quoting is
1680 added to PROGRAM and its arguments, but not to WRAPPER, so you
1682 until it executes your program, and then GDB takes control.
1684 You can use any program that eventually calls `execve' with its
1690 the debugged program, without setting the variable in your shell's
1702 randomization of the virtual address space of the started program.
1714 rear their ugly heads only when the program is loaded at certain
1715 addresses. If your bug disappears when you run the program under
1750 randomization of the virtual address space of the started program.
1756 4.3 Your Program's Arguments
1759 The arguments to your program can be specified by the arguments of the
1761 characters and performs redirection of I/O, and thence to your program.
1766 On non-Unix systems, the program is usually invoked directly by GDB,
1769 program, not by the shell.
1775 Specify the arguments to be used the next time your program is
1776 run. If `set args' has no arguments, `run' executes your program
1777 with no arguments. Once you have run your program with arguments,
1782 Show the arguments to give your program when it is started.
1787 4.4 Your Program's Environment
1795 When debugging, it can be useful to try running your program with a
1800 search path for executables) that will be passed to your program.
1819 your program when it starts. If you do not supply VARNAME, print
1821 your program. You can abbreviate `environment' as `env'.
1825 your program only, not for GDB itself. VALUE may be any string;
1827 interpretation is supplied by your program itself. The VALUE
1835 tells the debugged program, when subsequently run, that its user
1841 program. This is different from `set env VARNAME ='; `unset
1845 _Warning:_ On Unix systems, GDB runs your program using the shell
1849 BASH--any variables you set in that file affect your program. You may
1856 4.5 Your Program's Working Directory
1859 Each time you start your program with `run', it inherits its working
1876 the process being debugged (since a program can change its directory
1885 4.6 Your Program's Input and Output
1888 By default, the program you run under GDB does input and output to the
1891 your program was using and switches back to them when you continue
1892 running your program.
1896 program is using.
1898 You can redirect your program's input and/or output using shell
1903 starts your program, diverting its output to the file `outfile'.
1905 Another way to specify where your program should do input and output
1928 program.
1931 Set the tty for the program being debugged to /dev/ttyb.
1934 Show the current tty for the program being debugged.
1952 To use `attach', your program must be running in an environment
1957 When you use `attach', the debugger finds the program running in the
1959 program is not found) by using the source file search path (*note
1961 `file' command to load the program. *Note Commands to Specify Files:
1995 Kill the child process in which your program is running under GDB.
1998 running process. GDB ignores any core dump file while your program is
2001 On some operating systems, a program cannot be executed outside GDB
2003 `kill' command in this situation to permit running your program outside
2007 program, since on many systems it is impossible to modify an
2026 GDB represents the state of each program execution with an object
2076 begins empty, with no program. You can still assign or change the
2077 program assigned to the inferior at any time by using the `file'
2081 Adds N inferiors ready to execute the same program as inferior
2143 single program: e.g., `print myglobal' will simply display the value of
2148 debug session. You can do that with the `maint info program-spaces'
2151 `maint info program-spaces'
2152 Print a list of all program spaces currently being managed by GDB.
2154 GDB displays for each program space (in this order):
2156 1. the program space number assigned by GDB
2158 2. the name of the executable loaded into the program space,
2162 An asterisk `*' preceding the GDB program space number indicates
2163 the current program space.
2165 In addition, below each program space line, GDB prints extra
2167 example, the list of inferiors bound to the program space.
2169 (gdb) maint info program-spaces
2175 Here we can see that no inferior is running the program `hello',
2176 while `process 21561' is running the program `goodbye'. On some
2178 same program space. The most common example is that of debugging
2182 (gdb) maint info program-spaces
2188 program space as a result of inferior 1 having executed a `vfork'
2197 In some operating systems, such as HP-UX and Solaris, a single program
2200 threads of a single program are akin to multiple processes--except that
2223 with the program.
2237 while your program runs--but whenever GDB takes control, one thread in
2239 "current thread". Debugging commands show program information from the
2242 Whenever GDB detects a new thread in your program, it displays the
2255 a single integer--with each thread in your program.
2258 Display a summary of all threads currently in your program.
2269 cases, by the program itself.
2416 program forks, GDB will continue to debug the parent process and the
2426 child. While the child is sleeping, use the `ps' program to get its
2437 By default, when a program forks, GDB will continue to debug the
2444 Set the debugger response to a program call of `fork' or `vfork'.
2497 program, the breakpoint will also be set on the child process's `main'.
2510 Set debugger response to a program call of `exec'. An `exec' call
2511 replaces the program image of a process.
2517 new inferior. The program the process was running before the
2528 process 12020 is executing new program: prog2
2529 Program exited normally.
2549 process 12020 is executing new program: prog2
2550 Program exited normally.
2567 program's state, called a "checkpoint", and come back to it later.
2570 happened in the program since the `checkpoint' was saved. This
2575 Thus, if you're stepping thru a program and you think you're getting
2578 instead of having to restart your program from the beginning, you can
2587 Save a snapshot of the debugged program's current execution state.
2605 Restore the program state that was saved as checkpoint number
2606 CHECKPOINT-ID. All program variables, registers, stack frames
2613 only restores things that reside in the program being debugged,
2621 state of the program being debugged, plus a significant subset of the
2630 from eg. a serial device can be removed from internal program buffers,
2636 program to a previously saved point in time, and begin debugging it
2640 Finally, there is one bit of internal program state that will be
2641 different when you return to a checkpoint -- the program's process id.
2643 be different from the program's original PID. If your program has
2653 absolute address if you have to restart the program, since the absolute
2673 program before it terminates; or so that, if your program runs into
2676 Inside GDB, your program may stop for any of several reasons, such
2681 your program--but you can also explicitly request this information at
2684 `info program'
2685 Display information about the status of your program: whether it is
2701 A "breakpoint" makes your program stop whenever a certain point in the
2702 program is reached. For each breakpoint, you can add conditions to
2703 control in finer detail whether your program stops. You can set
2705 Breakpoints: Set Breaks.), to specify the place where your program
2707 program.
2712 in shared library routines that are not called directly by the program
2715 A "watchpoint" is a special breakpoint that stops your program when
2724 You can arrange to have values from your program displayed
2728 A "catchpoint" is another special breakpoint that stops your program
2733 other breakpoint. (To stop when your program receives a signal, use the
2741 disabled, it has no effect on your program until you enable it again.
2778 specify a LOCATION.) The breakpoint will stop your program just
2787 program only if a specific thread (*note Thread-Specific
2795 innermost, this makes your program stop as soon as control returns
2807 the breakpoint already existed when your program stopped.
2821 time your program stops there. *Note Disabling Breakpoints:
2832 targets. These targets will generate traps when a program
2849 program stops there. Also, like the `hbreak' command, the
2875 functions in a program, like this:
2912 Where the breakpoint is in your program, as a memory address.
2921 Where the breakpoint is in the source for your program, as a
2948 your program. There is nothing silly or meaningless about this. When
2953 your program. Examples of this situation are:
2996 repeatedly, as the program is executed. To support this use case, GDB
3005 After the program is run, whenever a new shared library is loaded,
3066 GDB normally implements breakpoints by replacing the program code at
3068 executed, given control to the debugger. By default, the program code
3069 is so modified only when the program is resumed. As soon as the
3070 program stops, GDB restores the original instructions. This behaviour
3095 GDB itself sometimes sets breakpoints in your program for special
3128 expression can use any operators valid in the program's native
3134 your program sets `global_ptr' and the expression produces a valid
3142 program and testing the variable's value each time, which is hundreds of
3144 catch errors where you have no clue what part of your program is the
3149 do not slow down the running of your program.
3153 expression EXPR is written into by the program and its value
3175 the program.
3179 written into by the program.
3245 insert all of them when you resume the execution of your program.
3247 time as the program is about to be resumed, GDB might not be able to
3249 be printed only when the program is resumed:
3267 variables were defined. In particular, when the program being debugged
3270 program, you will need to set all such watchpoints again. One way of
3296 kinds of program events, such as C++ exceptions or the loading of a
3326 program.
3370 Starting program: /tmp/catch-syscall
3386 Starting program: /tmp/catch-syscall
3404 Starting program: /tmp/catch-syscall
3411 Program exited normally.
3476 that returns control to you and cause your program either to abort
3507 that depends on the value of ID, you can stop your program when a
3509 breakpoints to stop your program when any of a number of exceptions are
3519 catchpoint once it has done its job and you no longer want your program
3524 where they are in your program. With the `delete' command you can
3537 a breakpoint where your program just stopped.
3583 * Enabled. The breakpoint stops your program. A breakpoint set
3586 * Disabled. The breakpoint has no effect on your program.
3588 * Enabled once. The breakpoint stops your program, but then becomes
3591 * Enabled for deletion. The breakpoint stops your program, but
3607 They become effective once again in stopping your program.
3611 these breakpoints immediately after stopping your program.
3615 deletes any of these breakpoints as soon as your program stops
3633 The simplest sort of breakpoint breaks every time your program reaches a
3637 evaluates the expression each time your program reaches it, and your
3638 program stops only if the condition is _true_.
3640 This is the converse of using assertions for program validation; in
3653 in your program. This can be useful, for example, to activate functions
3654 that log program progress, or to use your own print functions to format
3657 case, GDB might see the other breakpoint first and stop your program
3675 breakpoint BNUM stops your program only if the value of EXPRESSION
3698 no effect. But if your program reaches a breakpoint whose ignore count
3701 N, the breakpoint does not stop the next N times your program reaches
3706 COUNT times the breakpoint is reached, your program's execution
3713 When you use `continue' to resume execution of your program from a
3736 commands to execute when your program stops due to that breakpoint. For
3762 You can use breakpoint commands to start your program up again.
3798 that your program does not stop, and start with the `silent' command so
3828 you can edit the file in your favorite editing program, and remove
3844 This message is printed when you attempt to resume the program, since
3908 "Continuing" means resuming program execution until your program
3910 more "step" of your program, where "step" may mean either one line of
3913 program may stop even sooner, due to a breakpoint or a signal. (If it
3920 Resume program execution, at the address where your program last
3927 The argument IGNORE-COUNT is meaningful only when your program
3932 program is deemed to be the foreground program) are provided
3939 to go to an arbitrary location in your program.
3943 beginning of the function or the section of your program where a problem
3944 is believed to lie, run your program until it stops at that breakpoint,
3949 Continue running your program until control reaches a different
4026 automatically continues execution until the program counter is
4030 stepping though it, `until' makes your program continue execution
4035 `until' always stops your program if it attempts to exit the
4063 Continue running your program until either the specified location
4071 `96', issuing `until 99' will execute the program up to line `99'
4084 Continue running the program up to the given LOCATION. An
4100 instruction to be executed, each time your program stops. *Note
4119 A signal is an asynchronous event that can happen in a program. The
4122 a program gets when you type an interrupt character (often `Ctrl-c');
4123 `SIGSEGV' is the signal a program gets from referencing a place in
4125 alarm clock timer goes off (which happens only if your program has
4129 functioning of your program. Others, such as `SIGSEGV', indicate
4130 errors; these signals are "fatal" (they kill your program immediately)
4131 if the program has not specified in advance some other way to handle
4132 the signal. `SIGINT' does not indicate an error in your program, but
4134 to kill the program.
4137 program. You can tell GDB in advance what to do for each kind of
4141 `SIGALRM' be silently passed to your program (so as not to interfere
4142 with their role in the program's functioning) but to stop your program
4169 GDB should not stop your program when this signal happens. It may
4173 GDB should stop your program when this signal happens. This
4185 GDB should allow your program to see this signal; your program can
4191 GDB should not allow your program to see this signal. `nopass'
4194 When a signal stops your program, the signal is not visible to the
4195 program until you continue. Your program sees the signal then, if
4198 command with `pass' or `nopass' to control whether your program sees
4205 You can also use the `signal' command to prevent your program from
4207 or to give it any signal at any time. For example, if your program
4210 more execution; but your program would probably terminate immediately as
4212 you can continue with `signal 0'. *Note Giving your Program a Signal:
4217 program being debugged. This information is exported by the
4229 Program received signal SIGSEGV, Segmentation fault.
4264 controlling execution of your program within the debugger. In the
4266 program stops (for example, at a breakpoint or while being stepped),
4267 all other threads in the program are also stopped by GDB. On some
4276 * Background Execution:: Running your program asynchronously
4279 * Observer Mode:: GDB does not alter program behavior
4287 In all-stop mode, whenever your program stops under GDB for any reason,
4289 allows you to examine the overall state of the program, including
4293 Conversely, whenever you restart the program, _all_ threads start
4302 at a clean statement boundary, when the program stops.
4304 You might even find your program stopped in another thread after
4309 Whenever GDB stops your program, due to a breakpoint or a signal, it
4339 debug a program that forks and you want to hold the parent stopped (so
4366 operation in which you can examine stopped program threads in the
4384 or attach to your program:
4407 not whether the currently-executing program is being run in non-stop
4409 when GDB starts or connects to the target program, and it is generally
4421 GDB/MI Program Execution::) are always executed asynchronously in
4428 program, use `interrupt -a'.
4447 foreground execution, GDB waits for the program to report that some
4450 other commands while your program runs.
4474 *Note Starting your Program: Starting.
4506 commands that are valid in all-stop mode while the program is running
4509 You can interrupt your program while it is running in the background
4514 Suspend execution of the running program. In all-stop mode,
4516 only the current thread. To stop the whole program in non-stop
4525 When your program has multiple threads (*note Debugging Programs with
4536 specify that you only want GDB to stop the program when a
4542 the breakpoint applies to _all_ threads of your program.
4564 To handle this problem, your program should check the return value of
4583 multi-threaded program to behave differently than it would without GDB.
4588 prematurely, even though your program does not appear to stop.
4596 If you want to build on non-stop mode and observe program behavior
4672 program execution. When this variable is `off', the `interrupt'
4677 Show the current permission to interrupt or stop the program.
4686 When you are debugging a program, it is not unusual to realize that you
4689 program by running it backward.
4693 program was executing normally. Variables, registers etc. should
4698 When a program is executed in reverse, the instructions that have
4700 program counter runs backward, following the previous thread of
4712 Beginning at the point where your program last stopped, start
4718 Run the program backward until control reaches the start of a
4734 to be reverse-executed is _not_ the one pointed to by the program
4807 replay mode, the values of registers (including the program counter
4960 When your program has stopped, the first thing you need to know is
4963 Each time your program performs a function call, information about
4965 call in your program, the arguments of the call, and the local
4970 When your program stops, the GDB commands for examining the stack
4975 ask GDB for the value of a variable in your program, the value is found
4980 When your program stops, GDB automatically selects the currently
5003 When your program is started, the stack has only one frame, that of
5012 Inside your program, stack frames are identified by their addresses.
5021 upward. These numbers do not really exist in your program; they are
5053 A backtrace is a summary of how your program got where it is. It shows
5084 In a multi-threaded program, GDB by default shows the backtrace only
5089 debug a core dump of a multi-threaded program.
5092 name. The program counter value is also shown--unless you use `set
5094 line number, as well as the arguments to the function. The program
5108 The display for frame zero does not begin with a program counter value,
5109 indicating that your program has stopped at the beginning of the code
5118 If your program was compiled with optimizations, some compilers will
5193 Most commands for examining the stack and other data in your program
5210 addition, this can be useful when your program has multiple stacks
5217 pointer and a program counter.
5220 pointer, a program counter, and a memory stack pointer.
5247 also edit the program at the point of execution with your favorite
5248 editing program by typing `edit'. *Note Printing Source Lines: List,
5294 * the program counter saved in it (the address of execution in
5333 GDB can print parts of your program's source, since the debugging
5334 information recorded in the program tells GDB what source files were
5335 used to build it. When your program stops, GDB spontaneously prints
5438 program
5482 Specifies the program address ADDRESS. For line-oriented
5486 program which do not have debugging information or source files.
5525 editing program of your choice is invoked with the current line set to
5526 the active line in the program. Alternatively, there are several ways
5528 other parts of the program:
5632 The search path is used to find both program source files and GDB
5637 specifies how to rewrite source directories stored in the program's
5778 You can use the command `info line' to map source lines to program
5815 memory range is the function surrounding the program counter of
5817 program counter value; GDB dumps the function surrounding this
5836 If the range of memory being disassembled contains current program
5856 the program is stopped just after function prologue:
5900 Select the instruction set to use when disassembling the program
5915 disassembly of the next source line when execution of the program
5934 The usual way to examine data in your program is with the `print'
5936 prints the value of an expression of the language your program is
5968 * Variables:: Program variables
5983 * Core File Generation:: Cause a program dump its core
6000 compiled your program to include this information; see *note
6006 array to a function or assign it to a program variable, GDB copies the
6007 array to memory that is `malloc'ed in the target program.
6030 function where it is defined. *Note Program Variables: Variables.
6115 10.3 Program Variables
6119 your program.
6143 you can examine and use the variable `a' whenever your program is
6145 the variable `b' while your program is executing inside the block where
6201 Program or GCC: (gcc.info)Debugging Options.
6214 string type `"char"' as `char' without a sign. For program code
6233 determined size for which only a pointer exists in the program.
6243 example. If a program says
6362 For example, to print the program counter in hex (*note
6387 several formats, independently of your program's data types.
6480 program counter is shown with a `=>' marker. For example:
6503 When you are debugging a program running on a remote target machine
6504 (*note Remote Debugging::), you may wish to verify the program's image
6511 executable file of the program being debugged with the same
6525 display list" so that GDB prints its value each time your program stops.
6542 time your program stops. *Note Expressions: Expressions.
6555 time your program stops. Examining means in effect doing `x/FMT
6560 common name for the program counter; *note Registers: Registers.).
6593 is done when your program stops.
6608 `last_char', GDB displays this argument while your program continues to
6611 time your program stops where `last_char' is meaningful, you can enable
6916 program.
7033 * Pretty-printers registered with a program space are available only
7034 when debugging that program. *Note Progspaces In Python::, for
7035 more details on program spaces in Python.
7086 pretty-printers to list. Objects can be `global', the program
7088 within that program space (*note Objfiles In Python::). *Note
7226 entirely within GDB; they are not part of your program, and setting a
7228 program. That is why you can use them freely.
7237 expression, just as you would set a variable in your program. For
7298 when the program being debugged terminates.
7361 `$pc' and `$sp' are used for the program counter register and the stack
7364 processor status. For example, you could print the program counter in
7395 the operating system is not the same one that your program normally
7400 sense for your program), but the `info registers' command prints the
7482 your program.
7492 kernel for the program being debugged. GDB displays the contents
7498 specify for a program, but contains a system-dependent variety of
7735 10.18 How to Produce a Core File from Your Program
7740 primary use is post-mortem debugging of a program that crashed while it
7741 ran outside a debugger. A program that crashes automatically produces
7746 Occasionally, you may wish to produce a core file of the program you
7766 If the program you are debugging uses a different character set to
7770 inferior program uses we call the "target character set".
7774 protocol (*note Remote Debugging::) to debug a program running on an
7782 inferior program uses; you must tell it, using the `set target-charset'
7847 In this program, `ascii_hello' and `ibm1047_hello' are arrays
7851 We compile the program, and invoke the debugger on it:
7897 program
7914 program's strings again. Now the ASCII string is wrong, but GDB
8111 by the compiler, GDB can map from the running program back to
8116 your program during debugging. But, there are many cases where you may
8119 When you debug a program compiled with `-g -O', remember that the
8192 line and print a variable where your program stored the return
8208 You may need to compile your program specially to provide GDB with
8213 A program may define a macro at one point, remove that definition
8215 different points in the program, a macro may have different
8260 definitions for MACRO present in the program being debugged, as
8267 present in the program being debugged.
8295 Now, we compile the program using the GNU C compiler, GCC. We pass
8302 Now, we start GDB on our sample program:
8311 program is not running. GDB uses the current listing position to
8343 Once the program is running, GDB uses the macro definitions in force
8349 Starting program: /home/jimb/gdb/macros/play/sample
8405 the program's execution long enough for the developer to learn anything
8406 helpful about its behavior. If the program's correctness depends on
8408 program to change its behavior drastically, or perhaps fail, even when
8410 program's behavior without interrupting it.
8413 locations in the program, called "tracepoints", and arbitrary
8416 had when the program hit the tracepoints. The expressions may also
8422 program's behavior.
8476 points, also known as "markers", are embedded in the target program,
8517 address in the target program. *Note Specify Location::. The
8519 target program where the debugger will briefly stop, collect some
8520 data, and then allow the program to continue. Setting a
8569 your program is using. You can find all the marker identifiers in
8572 Tracepoint Markers. For example, in the following small program
8682 The simplest sort of tracepoint collects data every time your program
8686 with a condition evaluates the expression each time your program
8705 through the program; an unconditional tracepoint could end up
8829 the program. Other backends have similar mechanisms. Here's
8923 the program.
8939 Where the marker is in your program, as a memory address.
8942 Where the marker is in the source for your program, as a file
8944 program does not allow GDB to locate the source of the
9099 program--particularly if a conditional branch is stepped.
9151 memory or registers of the program being debugged. This means that
9153 behave as if we were currently debugging the program state as it was
9200 program counter. Search proceeds forward from the last examined
9230 no argument selects the next snapshot with the same program counter
9431 If your program is too large to fit completely in your target system's
9441 * Overlay Sample Program:: A sample program using overlays.
9453 adapt a program which is larger than 64 kilobytes to run on this system.
9455 One solution is to identify modules of your program which are
9457 these modules "overlays". Separate the overlays from the main program,
9459 program in instruction memory, but leave at least enough space there to
9472 | program | | main | .----| overlay 1 | load address
9473 | variables | | program | | +-----------+
9494 data and instruction address spaces. To map an overlay, the program
9499 except that the program variables and heap would share an address space
9500 with the main program and the overlay area.
9511 adapt a program to limited instruction memory. They introduce a new
9513 program:
9516 program must make sure that overlay is actually mapped.
9518 address, but in the wrong overlay, and your program will probably
9523 effect on your program's performance.
9531 program; see *note Overlay Description: (ld.info)Overlay
9567 To use GDB's overlay support, each overlay in your program must
9664 File: gdb.info, Node: Automatic Overlay Debugging, Next: Overlay Sample Program, Prev: Overlay Commands, Up: Overlays
9713 GDB to accurately keep track of which overlays are in program memory,
9719 File: gdb.info, Node: Overlay Sample Program, Prev: Automatic Overlay Debugging, Up: Overlays
9721 14.4 Overlay Sample Program
9724 When linking a program which uses overlays, you must place the overlays
9733 program, with linker scripts for a few systems, as part of its test
9734 suite. The program consists of the following files from
9738 The main program file.
9751 Linker scripts for linking the test program on the `d10v-elf' and
9754 You can build the test program using the `d10v-elf' GCC
9784 allowing you to express operations like the above in your program's
9786 consistent with the syntax of your program's native language. The
9821 This is most commonly a problem when you use a program, such as
9823 In that case, make the program use `#line' directives in its C output;
9825 original program, and will display that source code, not the generated
9888 interpreted the same way in your debugging session and your program.
9897 a program when the working language is not the same as the source
9917 That is, when your program stops in a frame (usually by encountering a
9925 entirely in one source language. However, program modules and libraries
9926 written in one source language can be used by a main program written in
9942 expressions that may involve variables in your program.
9980 as these help to ensure a program's correctness once it has been
9982 for range errors when your program is running.
9985 GDB does not check the statements in your program, it can check
9988 decide whether or not to check automatically based on your program's
10070 checking is meant to ensure program correctness by making sure
10170 Debugging Your Program or GCC: (gcc.info)Debugging Options.
10408 that do not exist in the program. It also cannot handle ellipsis
10439 expressions can use it just as expressions in your program do.
10444 Program Variables: Variables.).
10662 `Fruit' in the program currently being debugged, enter:
10666 To list ten program lines around the `initialize' class method,
10679 your program's source files contain more than one `create' method,
10818 all `COMMON' blocks visible at the current program location are
11328 a module, and ID is any declared identifier within your program, except
11381 * Stopping Before Main Program:: Debugging the program during elaboration.
11401 subprograms written into the program (which therefore may be
11416 program. As for other languages, it will enter Ada mode when stopped
11417 in a program that was translated from an Ada source file.
11533 regardless of context. Should your program redefine these names
11538 File: gdb.info, Node: Additions to Ada, Next: Stopping Before Main Program, Prev: Omissions from Ada, Up: Ada
11629 File: gdb.info, Node: Stopping Before Main Program, Next: Ada Tasks, Prev: Additions to Ada, Up: Ada
11634 It is sometimes necessary to debug the program during elaboration, and
11637 `adainit'. To run your program up to the beginning of elaboration,
11641 File: gdb.info, Node: Ada Tasks, Next: Ada Tasks and Core Files, Prev: Stopping Before Main Program, Up: Ada
11726 Name of the task in the program.
11780 specify that you only want GDB to stop the program when a
11786 breakpoint applies to _all_ tasks of your program.
11822 When inspecting a core file, as opposed to debugging a live program,
11846 Allows task switching when debugging a program that uses the
11850 Turn off task switching when debugging a program that uses the
11855 before the program is started.
11859 program using the Ravenscar Profile.
11892 program other than parameters and local variables whose simple
11946 program. This information is inherent in the text of your program and
11947 does not change as your program executes. GDB finds it in your
11948 program's symbol table, in the file indicated when you started GDB
11955 (*note Program Variables: Variables.). File names are recorded in
12047 information included in the program does not allow GDB to display
12065 regular expression REGEXP (or all types in your program, if you
12068 all types in your program whose names include the string `value',
12117 Print the names of all source files in your program for which
12145 Display all Objective-C classes in your program, or (with the
12151 Display all Objective-C selectors in your program, or (with the
12156 program to be replaced without stopping and restarting your
12157 program. For example, in VxWorks you can simply recompile a
12281 Once you think you have found an error in your program, you might want
12285 the program.
12288 locations, give your program a signal, restart it at a different
12295 * Signaling:: Giving your program a signal
12297 * Calling:: Calling your program's functions
12298 * Patching:: Patching your program
12325 of subcommands. For example, if your program has a variable `width',
12337 the program's variable `width', use
12342 with the names of program variables, it is a good idea to use the `set
12343 variable' command instead of just `set'. For example, if your program
12356 The program being debugged has been started already.
12358 Starting program: /home/smith/cc_progs/a.out
12364 The program variable `g' did not change, and you silently set the
12390 Ordinarily, when you continue your program, you do so at the place where
12405 register other than the program counter. If line LINESPEC is in a
12412 code of your program.
12416 is that this does not start your program running; it only changes the
12422 address `0x485', rather than at the address where your program stopped.
12426 up--perhaps with more breakpoints set--over a portion of a program that
12432 17.3 Giving your Program a Signal
12436 Resume execution where your program stopped, but immediately give
12442 giving a signal. This is useful when your program stopped on
12454 directly to your program.
12480 program stopped in the state that would exist if the function had just
12532 17.5 Calling Program Functions
12537 EXPR may include calls to functions in the program being debugged.
12544 execute a function from your program that does not return anything
12554 Similarly, with a C++ program it is possible for the function you
12565 function that GDB called in the program being debugged. If set to
12576 unhandled while in a function that GDB called in the program being
12600 By default, GDB opens the file containing your program's executable
12603 your program's binary.
12629 GDB needs to know the file name of the program to be debugged, both in
12630 order to read its symbol table and in order to start your program. To
12659 Use FILENAME as the program to be debugged. It is read for its
12661 program executed when you use the `run' command. If you do not
12665 program to run. You can change the value of this variable, for
12666 both GDB and your program, using the `path' command.
12682 Specify that the program to be run (but not the symbol table) is
12684 if necessary to locate your program. Omitting FILENAME means to
12690 table and program to run from the same file.
12693 program's symbol table.
12749 Note that the core file is ignored when your program is actually
12750 running under GDB. So, if you have been running your program and
12752 subprocess in which the program is running. To do this, use the
12761 into the program that is running. ADDRESS should be the memory
12791 load relocatable files into an already running program; such
12799 relocatable object file into the program in the normal way.
12843 Another command that can give you extra information about program
12905 file, rather than from the target program. For some targets
12913 contents of the section might change while the program is running,
12935 On HP-UX, if the program loads a library explicitly, GDB
12953 If your program uses lots of shared libraries with debug info that
12978 loads shared libraries required by your program for a core file or
12980 required by your program are loaded.
13017 Use PATH as the system root for the program being debugged. Any
13020 the target program's memory. If you use `set sysroot' to find
13144 needs to compare them to the file names recorded in the program's debug
13151 similar filesystem facilities violate that assumption. If your program
13176 GDB allows you to put a program's debugging information in a file
13499 This usually allows you to debug your program, though certain
13551 A "target" is the execution environment occupied by your program.
13553 Often, GDB runs in the same host environment as your program; in
13640 `target' refers to a program, not a machine.
13656 `target exec PROGRAM'
13657 An executable file. `target exec PROGRAM' is the same as
13658 `exec-file PROGRAM'.
13736 load address when you link the program; for other formats, like
13780 If you are trying to debug a program running on a machine that cannot
13800 * Server:: Using the gdbserver program
13811 program, since GDB needs symbol and debugging information. Start up
13812 GDB as usual, using the name of the local copy of your program as the
13817 for debugging your program; only the medium carrying the debugging
13873 will try to send it a `SIGTERM' signal. (If the program has
13878 commands to examine and change data. The remote program is already
13882 Whenever GDB is waiting for the remote program, if you type the
13883 interrupt character (often `Ctrl-c'), GDB attempts to stop the program.
13888 Interrupted while waiting for the program.
13896 When you have finished debugging the remote program, you can use
13946 20.3 Using the `gdbserver' Program
13949 `gdbserver' is a control program for Unix-like systems, which allows
13950 you to connect your program with a remote GDB via `target remote'--but
13957 sometimes useful nevertheless, because it is a much smaller program
13977 Run `gdbserver' on the target system. You need a copy of the program
13979 does not need your program's symbol table, so you can strip the program
13984 name of your program; and the arguments for your program. The usual
13987 target> gdbserver COMM PROGRAM [ ARGS ... ]
14011 20.3.1.1 Attaching to a Running Program
14025 target> gdbserver --attach COMM `pidof PROGRAM`
14027 In case more than one copy of PROGRAM is running, or PROGRAM has
14035 debugs the specified program only once. When the program exits, or you
14039 multi-process mode. When the debugged program exits, or you detach
14040 from it, GDB stays connected to `gdbserver' even though no program is
14042 or attach to a new program. The `run' command uses `set remote
14043 exec-file' (*note set remote exec-file::) to select the program to run.
14049 can connect using `target extended-remote' and start the program you
14070 `gdbserver' runs the specified wrapper program with a combined
14072 program to debug, then any arguments to the program. The wrapper runs
14073 until it executes your program, and then GDB gains control.
14075 You can use any program that eventually calls `execve' with its
14081 the debugged program, without setting the variable in `gdbserver''s
14109 GDB when using `gdbserver', since the program is already on the target.
14165 There are several ways to load the in-process agent in your program:
14168 You can link your program dynamically with the in-process agent
14190 available, the program needs to be linked with `-ldl'.
14194 find that the program is stopped at the dynamic loader's entry point,
14195 and no shared library has been loaded in the program's address space
14199 that is to run the program to the main procedure. E.g., if debugging a
14200 C or C++ program, start `gdbserver' like so:
14253 type `Ctrl-c' to interrupt the program running on the remote. If
14260 program.
14305 last program run).
14317 interrupt the remote program. `BREAK-g' is BREAK signal followed
14439 To debug a program running on another machine (the debugging
14441 prerequisites for the program to run by itself. For example, for a C
14442 program, you need:
14449 2. A C subroutine library to support your program's subroutine calls,
14452 3. A way of getting your program to the other machine--for example, a
14453 download program. These are often supplied by the hardware
14457 The next step is to arrange for your program to use a serial port to
14467 you must link with your program a few special-purpose subroutines
14471 On certain remote targets, you can use an auxiliary program
14472 `gdbserver' instead of linking a stub into your program. *Note
14473 Using the `gdbserver' Program: Server, for details.
14517 program stops. You must call this subroutine explicitly near the
14518 beginning of your program.
14521 This is the central workhorse, but your program never calls it
14525 `handle_exception' takes control when your program stops during
14530 sending summary information on the state of your program, then
14532 GDB needs, until you execute a GDB command that makes your program
14537 Use this auxiliary subroutine to make your program contain a
14545 your own program--simply running `target remote' from the host GDB
14549 to make certain your program stops at a predetermined point for the
14577 If you want GDB to be able to stop your program while it is running,
14617 function to make certain that the state of your program is stable.
14638 In summary, when your program is ready to debug, you must follow these
14646 2. Insert these lines near the top of your program:
14657 function in your program, that function is called when `GDB'
14662 4. Compile and link together: your program, the GDB debugging stub for
14668 6. Download your program to your target machine (or get it there by
14769 report information about the process running your program, or about any
14779 that process; otherwise display information about the program being
14791 Report the memory address space ranges accessible in the program,
14875 A typical DJGPP program uses 3 segments: a code segment, a data
14887 the debugged program's data segment:
14902 for every page of memory that is mapped into the program's address
14915 These commands are useful when your program uses "DMA" (Direct
14916 Memory Access), which needs physical addresses to program the DMA
14940 address of all variables and functions in a DJGPP program, will be
15095 Very often on windows, some of the DLLs that your program relies on do
15102 Note that before the debugged program has started execution, no DLLs
15104 start the program -- either by setting a breakpoint or letting the
15105 program run once to completion. It is also possible to force GDB to
15120 In some cases there will be name clashes within a program
15155 in a DLL are not available unless the program is running. This means
15157 function within a DLL without a running program.
15184 program starts execution. However, under these circumstances, GDB can't
15419 both the Unix host and on the VxWorks target. The program `gdb' is
15477 path (*note Your Program's Environment: Environment.); if it fails to
15502 For instance, a program `prog.o' may reside in `VXPATH/vw/demo/rdb' in
15504 program, type this on VxWorks:
15800 target FPGA. The Xilinx Microprocessor Debugger (XMD) program
15818 Use this command to download a program to the MicroBlaze target.
15840 To run a program on the board, start up `gdb' with the name of
15841 your program as the argument. To connect to the board, use the
15843 port connected to the board. If the program has not already been
15848 serial port, and loads and runs a program called PROG through the
15919 waiting for your program to stop. In that case, GDB waits forever
15920 because it has no way of knowing how long the program is going to
16002 interfere with normal program execution and is thus much faster.
16180 Sparclet target. The program `gdb' is installed and executed on the
16189 information and `-Ttext' to relocate the program to where you wish to
16221 The GDB command `file' lets you choose with program to debug.
16230 Your Program's Environment: Environment.). If it fails to find a file,
16265 Since the file format is aout, the program must be loaded to the
16269 program `prog' was linked to text address 0x1201000, with data at
16275 If the code is loaded at a different address then what the program
16292 Starting program: prog
16307 You must use an additional command to debug the program. For
16331 `file' command to load a new program image, the `run' command to run
16332 your program, and so on.
16987 GDB needs to know the ABI used for your program's C++ objects. The
16990 if your program contains code using multiple C++ ABI's or if GDB can
16991 not identify your program's ABI correctly, you can tell GDB which ABI
17048 you try to run a program which is already running:
17051 The program being debugged has been started already.
17482 execution stops in your program: before breakpoint commands are run,
17599 variables and symbols, changes in how the program being debugged is
17689 by TEMPLATE, exactly as a C program would do by executing the code
17841 print using GDB's output-paging streams. A Python program which
17861 * Progspaces In Python:: Program spaces.
17947 GDB is not thread-safe. If your Python program uses multiple
18108 GDB provides values it obtains from the inferior program in an object
18171 program that includes RTTI for the object in question.
18220 declared in your C program as
18643 `gdb.Objfile' in the current program space and iteratively calls each
18647 program space, calling each enabled function until an object is
19454 23.2.2.14 Program Spaces In Python
19457 A program space, or "progspace", represents a symbolic view of an
19458 address space. It consists of all of the objfiles of the program.
19459 *Note Objfiles In Python::. *Note program spaces: Inferiors and
19460 Programs, for more details about program spaces.
19466 This function returns the program space of the currently selected
19540 When the debugged program stops, GDB is able to analyze its call stack
19637 determined by the frame's current program counter). VARIABLE
19871 The value does not actually exist in the program.
19897 Indicates the current program counter address. This
20460 program registers and GDB commands in separate text windows. The TUI
20482 The source window shows the source file of the program. The
20486 The assembly window shows the disassembly output of the program.
20492 The source and assembly windows show the current program position by
20518 current thread changes, when the frame changes, or when the program
20549 When there is no symbol corresponding to the current program
20557 Indicates the current program counter address.
20821 source files for the program you are debugging with GDB.
20835 input and output done by the program you are debugging.
20842 interacting with your program. In particular, you can send
20859 that can control the execution and describe the state of your program.
20864 program resides. If you only specify the file name, then Emacs sets
20866 previous buffer. In this case, GDB may find your program by searching
20877 By default, `M-x gdb' calls the program called `gdb'. If you need
20906 Continue execution of your program, like the GDB `continue'
20994 * GDB/MI Program Context::
20996 * GDB/MI Program Execution::
21375 * TARGET-STREAM-OUTPUT is the output produced by the target program.
21412 program being debugged to the user is called a "front end".
21607 A thread group became associated with a running program, either
21608 because the program was just started or the thread group was
21609 attached to a program. The ID field contains the GDB identifier
21614 A thread group is no longer associated with a running program,
21615 either because the program has exited, or because it was detached
21640 Reports that a new library file was loaded by the program. This
21654 Reports that a library was unloaded by the program. This
21733 Whenever a `*stopped' record is emitted because the program stopped
21764 Program Execution
21767 Program execution generates asynchronous records and MI gives the
21854 File: gdb.info, Node: GDB/MI Breakpoint Commands, Next: GDB/MI Program Context, Prev: GDB/MI Command Description Format, Up: GDB/MI
21917 program, that is, printing of values of some variables whenever
21946 Breakpoint NUMBER will stop the program only if the condition in
22336 stop the program execution twice: first for the variable changing
22363 program execution. Note that once the watchpoint goes out of scope, it
22433 File: gdb.info, Node: GDB/MI Program Context, Next: GDB/MI Thread Commands, Prev: GDB/MI Breakpoint Commands, Up: GDB/MI
22435 27.9 GDB/MI Program Context
22446 Set the inferior program arguments, to be used in the next
22594 File: gdb.info, Node: GDB/MI Thread Commands, Next: GDB/MI Program Execution, Prev: GDB/MI Program Context, Up: GDB/MI
22750 File: gdb.info, Node: GDB/MI Program Execution, Next: GDB/MI Stack Manipulation, Prev: GDB/MI Thread Commands, Up: GDB/MI
22752 27.11 GDB/MI Program Execution
22767 Resumes the execution of the inferior program, which will continue
22810 Resumes the execution of the inferior program until the current
22813 the inferior program until the point where current function was called.
22857 a non-running program, an error message will be printed.
22903 Resumes execution of the inferior program at the location specified
22927 Resumes execution of the inferior program, stopping when the
22931 the inferior program, stopping at the beginning of the previous source
22959 call, continues until the function returns. If the program stops at an
22964 the inferior program, stopping at the previous instruction. If the
23038 executes until either a breakpoint is encountered or the program exits.
23039 In the latter case the output will include an exit code, if the program
23067 Program exited normally:
23077 Program exited exceptionally:
23087 Another way the program can terminate is if it receives a signal
23102 Resumes execution of the inferior program, stopping when the
23106 reverse execution of the inferior program, stopping at the beginning of
23146 inferior program, stopping at the previously executed instruction. The
23149 address at which the program stopped will be printed as well.
23208 File: gdb.info, Node: GDB/MI Stack Manipulation, Next: GDB/MI Variable Objects, Prev: GDB/MI Program Execution, Up: GDB/MI
23597 each time the program stops. Instead, MI provides an update command
24074 option, to reduce the number of MI commands needed on each program stop.
25099 program addresses for the given source filename. The entries are
25473 which the target program is, in the following form:
25908 Set terminal for future runs of the program being debugged.
25931 Show terminal for future runs of program being debugged.
26013 Whether the program is running, how it stopped, etc.
26195 28.6 Running the Program
26198 When the program starts executing due to a GDB command such as `step'
26203 is output. When the program stops,
26208 annotations describe how the program stopped.
26211 The program exited, and EXIT-STATUS is the exit status (zero for
26215 The program exited with a signal. After the `^Z^Zsignalled', the
26236 just saying that the program received the signal, not that it was
26240 The program hit breakpoint number NUMBER.
26243 The program hit watchpoint number NUMBER.
26262 program associated with the source which is being displayed. ADDR is
26273 interface. A JIT compiler is a program or library that generates native
26280 program's symbols and debug information. In order to debug programs
26281 that use JIT compilation, GDB has an interface that allows the program
26284 If you are using GDB to debug a program that uses this interface,
26309 These are the relevant struct declarations that a C program should
26512 * What compiler (and its version) was used to compile the program
26548 program such as `script', which is available on many Unix systems.
26594 Sometimes with a program as complicated as GDB it is very hard to
26595 construct an example that will make the program follow a certain
26897 When a program which uses the Readline library starts up, the init
27247 application-specific settings. Each program using the
27250 sequences to functions useful for a specific program. For
28072 your DVI output program.
28087 standalone `info' program, available as part of the GNU Texinfo
28101 a program to print its DVI output files, and `texinfo.tex', the Texinfo
28104 TeX is a typesetting program; it does not print files directly, but
28106 you need a program to print DVI files. If your system has TeX
28107 installed, chances are it has such a program. The precise command to
28118 If you have TeX and a DVI printer program installed, you can typeset
28124 Then give `gdb.dvi' to your DVI printing program.
28203 If GDB is using the `iconv' program which is installed in a
28206 that contains the `iconv' program.
28229 `gdb' program.
28314 shell to start your program--some systems refuse to let GDB debug child
28327 the source directory. If your `make' program handles the `VPATH'
28329 builds the `gdb' program specified there.
28365 When you run `make' to build a program or library, you must run it
28616 This is supported only on systems which support aborting a program
28682 The program being debugged stopped while in a function called from GDB.
28740 This command prints, for each object file in the program, various
28850 by GDB and how much time was spend by the program been debugged.
28914 machine, you might want your program to do something special if it
28949 incorporated in your program) sends a RESPONSE. In the case of step
29060 persistent. The `R' packet is used to restart the program being
29075 Initialized `argv[]' array passed into program. ARGLEN specifies
29301 Restart the program being debugged. XX, while needed, is ignored.
29483 Run the program FILENAME, passing it each ARGUMENT on its command
29485 FILENAME is an empty string, the stub may use a default program
29486 (e.g. the last program run). The program is created in the stopped
29652 The program received signal number AA (a two-digit hexadecimal
29656 The program received signal number AA (a two-digit hexadecimal
29723 program's console output. This can happen at any time while the
29724 program is running and the debugger should continue to wait for
29935 ELF `PT_LOAD' program headers), GDB will relocate entire
29944 conventionally contains program code, to a starting address
30426 Targets which maintain a list of libraries in the program's
30853 containing program code. Since these areas never change, they
30947 requesting values while the program is running.
30973 exist in the target program. GDB sends `qTfSTM' to get the first
31005 target program at ADDRESS. Replies to this packet follow the
31158 When a program on the remote target is running, GDB may attempt to
31185 at interrupting the running program, it should send one of the stop
31187 successfully stopping the program in all-stop mode, and a stop reply
31189 program is stopped are discarded.
32651 the program's execution long enough for the developer to learn anything
32652 helpful about its behavior. If the program's correctness depends on its
32654 program to fail, even when the code itself is correct. It is useful to
32655 be able to observe the program's behavior without interrupting it.
32658 locations in the program, and arbitrary expressions to evaluate when
32660 examine the values those expressions had when the program hit the trace
32666 quickly and unobtrusively, hopefully not disturbing the program's
32745 program, or call the program's functions; we assume that these
33126 * The user selects trace points in the program's code at which GDB
33131 those objects' contents are recorded as the program runs, or
33684 Pointers to unspecified code and data. The program counter and
34020 share and change all versions of a program--to make sure it remains
34038 For example, if you distribute copies of such a program, whether
34066 Finally, every program is threatened constantly by software patents.
34069 avoid the special danger that patents applied to a free program could
34071 patents cannot be used to render the program non-free.
34087 "The Program" refers to any copyrightable work licensed under this
34096 A "covered work" means either the unmodified Program or a work
34097 based on the Program.
34170 copyright on the Program, and are irrevocable provided the stated
34172 permission to run the unmodified Program. The output from running
34212 You may convey verbatim copies of the Program's source code as you
34218 give all recipients a copy of this License along with the Program.
34225 You may convey a work based on the Program, or the modifications to
34226 produce it from the Program, in the form of source code under the
34248 Appropriate Legal Notices; however, if the Program has
34255 program, in or on a volume of a storage or distribution medium, is
34370 entire Program shall be treated as though they were included in
34372 law. If additional permissions apply only to part of the Program,
34374 entire Program remains governed by this License without regard to
34414 restrictions" within the meaning of section 10. If the Program as
34464 run a copy of the Program. Ancillary propagation of a covered work
34498 using, selling, offering for sale, or importing the Program or any
34504 License of the Program or a work on which the Program is based.
34584 convey the Program, the only way you could satisfy both those
34586 the Program.
34608 Program specifies that a certain numbered version of the GNU
34612 Free Software Foundation. If the Program does not specify a
34616 If the Program specifies that a proxy can decide which future
34619 authorizes you to choose that version for the Program.
34628 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
34630 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
34634 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
34635 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
34642 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
34645 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
34647 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
34657 connection with the Program, unless a warranty or assumption of
34658 liability accompanies a copy of the Program in return for a fee.
34667 If you develop a new program, and you want it to be of the greatest
34672 To do so, attach the following notices to the program. It is safest
34677 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
34680 This program is free software: you can redistribute it and/or modify
34685 This program is distributed in the hope that it will be useful, but
34691 along with this program. If not, see `http://www.gnu.org/licenses/'.
34696 If the program does terminal interaction, make it output a short
34699 PROGRAM Copyright (C) YEAR NAME OF AUTHOR
34700 This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
34706 program's commands might be different; for a GUI interface, you would
34710 school, if any, to sign a "copyright disclaimer" for the program, if
34715 program into proprietary programs. If your program is a subroutine
34752 free program should come with manuals providing the same freedoms
35202 If your document contains nontrivial examples of program code, we
35330 * -environment-cd: GDB/MI Program Context.
35332 * -environment-directory: GDB/MI Program Context.
35334 * -environment-path: GDB/MI Program Context.
35336 * -environment-pwd: GDB/MI Program Context.
35339 * -exec-arguments: GDB/MI Program Context.
35341 * -exec-continue: GDB/MI Program Execution.
35343 * -exec-finish: GDB/MI Program Execution.
35345 * -exec-interrupt: GDB/MI Program Execution.
35347 * -exec-jump: GDB/MI Program Execution.
35349 * -exec-next: GDB/MI Program Execution.
35351 * -exec-next-instruction: GDB/MI Program Execution.
35353 * -exec-return: GDB/MI Program Execution.
35355 * -exec-run: GDB/MI Program Execution.
35357 * -exec-step: GDB/MI Program Execution.
35359 * -exec-step-instruction: GDB/MI Program Execution.
35361 * -exec-until: GDB/MI Program Execution.
35602 * arguments (to your program): Arguments. (line 6)
35625 * attach to a program by name: Server. (line 79)
35711 * breakpointing Ada elaboration code: Stopping Before Main Program.
36012 * deliver a signal to a program: Signaling. (line 6)
36151 * environment (of your program): Environment. (line 6)
36653 * info program: Stopping. (line 18)
36889 * maint info program-spaces: Inferiors and Programs.
37160 * overlay example program: Overlay Sample Program.
37326 * program counter register: Registers. (line 26)
37327 * program entry point: Backtrace. (line 93)
37565 * rewind program state: Checkpoint/Restart. (line 6)
38268 * task switching with program using Ravenscar Profile: Ravenscar Profile.
38524 * working directory (of your program): Working Directory. (line 6)
38710 Node: Overlay Sample Program402907
38757 Node: Stopping Before Main Program472277
38918 Node: GDB/MI Program Context891421
38920 Node: GDB/MI Program Execution899642
