This is ./gdb.info, produced by makeinfo version 4.0b from gdb.texinfo. INFO-DIR-SECTION Programming & development tools. START-INFO-DIR-ENTRY * Gdb: (gdb). The GNU debugger. END-INFO-DIR-ENTRY This file documents the GNU debugger GDB. This is the Ninth Edition, January 2002, of `Debugging with GDB: the GNU Source-Level Debugger' for GDB Version 5.1.1. Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002 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 Free Software Foundation's Back-Cover Text is: "You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development."  File: gdb.info, Node: GDB/MI Program Control, Next: GDB/MI Miscellaneous Commands, Prev: GDB/MI Data Manipulation, Up: GDB/MI GDB/MI Program control ====================== Program termination ................... As a result of execution, the inferior program can run to completion, if it doesn't encounter any breakpoints. In this case the output will include an exit code, if the program has exited exceptionally. Examples ........ Program exited normally: (gdb) -exec-run ^running (gdb) x = 55 *stopped,reason="exited-normally" (gdb) Program exited exceptionally: (gdb) -exec-run ^running (gdb) x = 55 *stopped,reason="exited",exit-code="01" (gdb) Another way the program can terminate is if it receives a signal such as `SIGINT'. In this case, GDB/MI displays this: (gdb) *stopped,reason="exited-signalled",signal-name="SIGINT", signal-meaning="Interrupt" The `-exec-abort' Command ------------------------- Synopsis ........ -exec-abort Kill the inferior running program. GDB Command ........... The corresponding GDB command is `kill'. Example ....... N.A. The `-exec-arguments' Command ----------------------------- Synopsis ........ -exec-arguments ARGS Set the inferior program arguments, to be used in the next `-exec-run'. GDB Command ........... The corresponding GDB command is `set args'. Example ....... Don't have one around. The `-exec-continue' Command ---------------------------- Synopsis ........ -exec-continue Asynchronous command. Resumes the execution of the inferior program until a breakpoint is encountered, or until the inferior exits. GDB Command ........... The corresponding GDB corresponding is `continue'. Example ....... -exec-continue ^running (gdb) @Hello world *stopped,reason="breakpoint-hit",bkptno="2",frame={func="foo",args=[], file="hello.c",line="13"} (gdb) The `-exec-finish' Command -------------------------- Synopsis ........ -exec-finish Asynchronous command. Resumes the execution of the inferior program until the current function is exited. Displays the results returned by the function. GDB Command ........... The corresponding GDB command is `finish'. Example ....... Function returning `void'. -exec-finish ^running (gdb) @hello from foo *stopped,reason="function-finished",frame={func="main",args=[], file="hello.c",line="7"} (gdb) Function returning other than `void'. The name of the internal GDB variable storing the result is printed, together with the value itself. -exec-finish ^running (gdb) *stopped,reason="function-finished",frame={addr="0x000107b0",func="foo", args=[{name="a",value="1"],{name="b",value="9"}}, file="recursive2.c",line="14"}, gdb-result-var="$1",return-value="0" (gdb) The `-exec-interrupt' Command ----------------------------- Synopsis ........ -exec-interrupt Asynchronous command. Interrupts the background execution of the target. Note how the token associated with the stop message is the one for the execution command that has been interrupted. The token for the interrupt itself only appears in the `^done' output. If the user is trying to interrupt a non-running program, an error message will be printed. GDB Command ........... The corresponding GDB command is `interrupt'. Example ....... (gdb) 111-exec-continue 111^running (gdb) 222-exec-interrupt 222^done (gdb) 111*stopped,signal-name="SIGINT",signal-meaning="Interrupt", frame={addr="0x00010140",func="foo",args=[],file="try.c",line="13"} (gdb) (gdb) -exec-interrupt ^error,msg="mi_cmd_exec_interrupt: Inferior not executing." (gdb) The `-exec-next' Command ------------------------ Synopsis ........ -exec-next Asynchronous command. Resumes execution of the inferior program, stopping when the beginning of the next source line is reached. GDB Command ........... The corresponding GDB command is `next'. Example ....... -exec-next ^running (gdb) *stopped,reason="end-stepping-range",line="8",file="hello.c" (gdb) The `-exec-next-instruction' Command ------------------------------------ Synopsis ........ -exec-next-instruction Asynchronous command. Executes one machine instruction. If the instruction is a function call continues until the function returns. If the program stops at an instruction in the middle of a source line, the address will be printed as well. GDB Command ........... The corresponding GDB command is `nexti'. Example ....... (gdb) -exec-next-instruction ^running (gdb) *stopped,reason="end-stepping-range", addr="0x000100d4",line="5",file="hello.c" (gdb) The `-exec-return' Command -------------------------- Synopsis ........ -exec-return Makes current function return immediately. Doesn't execute the inferior. Displays the new current frame. GDB Command ........... The corresponding GDB command is `return'. Example ....... (gdb) 200-break-insert callee4 200^done,bkpt={number="1",addr="0x00010734", file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8"} (gdb) 000-exec-run 000^running (gdb) 000*stopped,reason="breakpoint-hit",bkptno="1", frame={func="callee4",args=[], file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8"} (gdb) 205-break-delete 205^done (gdb) 111-exec-return 111^done,frame={level="0 ",func="callee3", args=[{name="strarg", value="0x11940 \"A string argument.\""}], file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="18"} (gdb) The `-exec-run' Command ----------------------- Synopsis ........ -exec-run Asynchronous command. Starts execution of the inferior from the beginning. The inferior executes until either a breakpoint is encountered or the program exits. GDB Command ........... The corresponding GDB command is `run'. Example ....... (gdb) -break-insert main ^done,bkpt={number="1",addr="0x0001072c",file="recursive2.c",line="4"} (gdb) -exec-run ^running (gdb) *stopped,reason="breakpoint-hit",bkptno="1", frame={func="main",args=[],file="recursive2.c",line="4"} (gdb) The `-exec-show-arguments' Command ---------------------------------- Synopsis ........ -exec-show-arguments Print the arguments of the program. GDB Command ........... The corresponding GDB command is `show args'. Example ....... N.A. The `-exec-step' Command ------------------------ Synopsis ........ -exec-step Asynchronous command. Resumes execution of the inferior program, stopping when the beginning of the next source line is reached, if the next source line is not a function call. If it is, stop at the first instruction of the called function. GDB Command ........... The corresponding GDB command is `step'. Example ....... Stepping into a function: -exec-step ^running (gdb) *stopped,reason="end-stepping-range", frame={func="foo",args=[{name="a",value="10"}, {name="b",value="0"}],file="recursive2.c",line="11"} (gdb) Regular stepping: -exec-step ^running (gdb) *stopped,reason="end-stepping-range",line="14",file="recursive2.c" (gdb) The `-exec-step-instruction' Command ------------------------------------ Synopsis ........ -exec-step-instruction Asynchronous command. Resumes the inferior which executes one machine instruction. The output, once GDB has stopped, will vary depending on whether we have stopped in the middle of a source line or not. In the former case, the address at which the program stopped will be printed as well. GDB Command ........... The corresponding GDB command is `stepi'. Example ....... (gdb) -exec-step-instruction ^running (gdb) *stopped,reason="end-stepping-range", frame={func="foo",args=[],file="try.c",line="10"} (gdb) -exec-step-instruction ^running (gdb) *stopped,reason="end-stepping-range", frame={addr="0x000100f4",func="foo",args=[],file="try.c",line="10"} (gdb) The `-exec-until' Command ------------------------- Synopsis ........ -exec-until [ LOCATION ] Asynchronous command. Executes the inferior until the LOCATION specified in the argument is reached. If there is no argument, the inferior executes until a source line greater than the current one is reached. The reason for stopping in this case will be `location-reached'. GDB Command ........... The corresponding GDB command is `until'. Example ....... (gdb) -exec-until recursive2.c:6 ^running (gdb) x = 55 *stopped,reason="location-reached",frame={func="main",args=[], file="recursive2.c",line="6"} (gdb) The `-file-exec-and-symbols' Command ------------------------------------ Synopsis ........ -file-exec-and-symbols FILE Specify the executable file to be debugged. This file is the one from which the symbol table is also read. If no file is specified, the command clears the executable and symbol information. If breakpoints are set when using this command with no arguments, GDB will produce error messages. Otherwise, no output is produced, except a completion notification. GDB Command ........... The corresponding GDB command is `file'. Example ....... (gdb) -file-exec-and-symbols /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx ^done (gdb) The `-file-exec-file' Command ----------------------------- Synopsis ........ -file-exec-file FILE Specify the executable file to be debugged. Unlike `-file-exec-and-symbols', the symbol table is _not_ read from this file. If used without argument, GDB clears the information about the executable file. No output is produced, except a completion notification. GDB Command ........... The corresponding GDB command is `exec-file'. Example ....... (gdb) -file-exec-file /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx ^done (gdb) The `-file-list-exec-sections' Command -------------------------------------- Synopsis ........ -file-list-exec-sections List the sections of the current executable file. GDB Command ........... The GDB command `info file' shows, among the rest, the same information as this command. `gdbtk' has a corresponding command `gdb_load_info'. Example ....... N.A. The `-file-list-exec-source-files' Command ------------------------------------------ Synopsis ........ -file-list-exec-source-files List the source files for the current executable. GDB Command ........... There's no GDB command which directly corresponds to this one. `gdbtk' has an analogous command `gdb_listfiles'. Example ....... N.A. The `-file-list-shared-libraries' Command ----------------------------------------- Synopsis ........ -file-list-shared-libraries List the shared libraries in the program. GDB Command ........... The corresponding GDB command is `info shared'. Example ....... N.A. The `-file-list-symbol-files' Command ------------------------------------- Synopsis ........ -file-list-symbol-files List symbol files. GDB Command ........... The corresponding GDB command is `info file' (part of it). Example ....... N.A. The `-file-symbol-file' Command ------------------------------- Synopsis ........ -file-symbol-file FILE Read symbol table info from the specified FILE argument. When used without arguments, clears GDB's symbol table info. No output is produced, except for a completion notification. GDB Command ........... The corresponding GDB command is `symbol-file'. Example ....... (gdb) -file-symbol-file /kwikemart/marge/ezannoni/TRUNK/mbx/hello.mbx ^done (gdb)  File: gdb.info, Node: GDB/MI Miscellaneous Commands, Next: GDB/MI Stack Manipulation, Prev: GDB/MI Program Control, Up: GDB/MI Miscellaneous GDB commands in GDB/MI ==================================== The `-gdb-exit' Command ----------------------- Synopsis ........ -gdb-exit Exit GDB immediately. GDB Command ........... Approximately corresponds to `quit'. Example ....... (gdb) -gdb-exit The `-gdb-set' Command ---------------------- Synopsis ........ -gdb-set Set an internal GDB variable. GDB Command ........... The corresponding GDB command is `set'. Example ....... (gdb) -gdb-set $foo=3 ^done (gdb) The `-gdb-show' Command ----------------------- Synopsis ........ -gdb-show Show the current value of a GDB variable. GDB command ........... The corresponding GDB command is `show'. Example ....... (gdb) -gdb-show annotate ^done,value="0" (gdb) The `-gdb-version' Command -------------------------- Synopsis ........ -gdb-version Show version information for GDB. Used mostly in testing. GDB Command ........... There's no equivalent GDB command. GDB by default shows this information when you start an interactive session. Example ....... (gdb) -gdb-version ~GNU gdb 5.2.1 ~Copyright 2000 Free Software Foundation, Inc. ~GDB is free software, covered by the GNU General Public License, and ~you are welcome to change it and/or distribute copies of it under ~ certain conditions. ~Type "show copying" to see the conditions. ~There is absolutely no warranty for GDB. Type "show warranty" for ~ details. ~This GDB was configured as "--host=sparc-sun-solaris2.5.1 --target=ppc-eabi". ^done (gdb)  File: gdb.info, Node: GDB/MI Stack Manipulation, Next: GDB/MI Symbol Query, Prev: GDB/MI Miscellaneous Commands, Up: GDB/MI GDB/MI Stack Manipulation Commands ================================== The `-stack-info-frame' Command ------------------------------- Synopsis ........ -stack-info-frame Get info on the current frame. GDB Command ........... The corresponding GDB command is `info frame' or `frame' (without arguments). Example ....... N.A. The `-stack-info-depth' Command ------------------------------- Synopsis ........ -stack-info-depth [ MAX-DEPTH ] Return the depth of the stack. If the integer argument MAX-DEPTH is specified, do not count beyond MAX-DEPTH frames. GDB Command ........... There's no equivalent GDB command. Example ....... For a stack with frame levels 0 through 11: (gdb) -stack-info-depth ^done,depth="12" (gdb) -stack-info-depth 4 ^done,depth="4" (gdb) -stack-info-depth 12 ^done,depth="12" (gdb) -stack-info-depth 11 ^done,depth="11" (gdb) -stack-info-depth 13 ^done,depth="12" (gdb) The `-stack-list-arguments' Command ----------------------------------- Synopsis ........ -stack-list-arguments SHOW-VALUES [ LOW-FRAME HIGH-FRAME ] Display a list of the arguments for the frames between LOW-FRAME and HIGH-FRAME (inclusive). If LOW-FRAME and HIGH-FRAME are not provided, list the arguments for the whole call stack. The SHOW-VALUES argument must have a value of 0 or 1. A value of 0 means that only the names of the arguments are listed, a value of 1 means that both names and values of the arguments are printed. GDB Command ........... GDB does not have an equivalent command. `gdbtk' has a `gdb_get_args' command which partially overlaps with the functionality of `-stack-list-arguments'. Example ....... (gdb) -stack-list-frames ^done, stack=[ frame={level="0 ",addr="0x00010734",func="callee4", file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="8"}, frame={level="1 ",addr="0x0001076c",func="callee3", file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="17"}, frame={level="2 ",addr="0x0001078c",func="callee2", file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="22"}, frame={level="3 ",addr="0x000107b4",func="callee1", file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="27"}, frame={level="4 ",addr="0x000107e0",func="main", file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="32"}] (gdb) -stack-list-arguments 0 ^done, stack-args=[ frame={level="0",args=[]}, frame={level="1",args=[name="strarg"]}, frame={level="2",args=[name="intarg",name="strarg"]}, frame={level="3",args=[name="intarg",name="strarg",name="fltarg"]}, frame={level="4",args=[]}] (gdb) -stack-list-arguments 1 ^done, stack-args=[ frame={level="0",args=[]}, frame={level="1", args=[{name="strarg",value="0x11940 \"A string argument.\""}]}, frame={level="2",args=[ {name="intarg",value="2"}, {name="strarg",value="0x11940 \"A string argument.\""}]}, {frame={level="3",args=[ {name="intarg",value="2"}, {name="strarg",value="0x11940 \"A string argument.\""}, {name="fltarg",value="3.5"}]}, frame={level="4",args=[]}] (gdb) -stack-list-arguments 0 2 2 ^done,stack-args=[frame={level="2",args=[name="intarg",name="strarg"]}] (gdb) -stack-list-arguments 1 2 2 ^done,stack-args=[frame={level="2", args=[{name="intarg",value="2"}, {name="strarg",value="0x11940 \"A string argument.\""}]}] (gdb) The `-stack-list-frames' Command -------------------------------- Synopsis ........ -stack-list-frames [ LOW-FRAME HIGH-FRAME ] List the frames currently on the stack. For each frame it displays the following info: `LEVEL' The frame number, 0 being the topmost frame, i.e. the innermost function. `ADDR' The `$pc' value for that frame. `FUNC' Function name. `FILE' File name of the source file where the function lives. `LINE' Line number corresponding to the `$pc'. If invoked without arguments, this command prints a backtrace for the whole stack. If given two integer arguments, it shows the frames whose levels are between the two arguments (inclusive). If the two arguments are equal, it shows the single frame at the corresponding level. GDB Command ........... The corresponding GDB commands are `backtrace' and `where'. Example ....... Full stack backtrace: (gdb) -stack-list-frames ^done,stack= [frame={level="0 ",addr="0x0001076c",func="foo", file="recursive2.c",line="11"}, frame={level="1 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="2 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="3 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="4 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="5 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="6 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="7 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="8 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="9 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="10",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="11",addr="0x00010738",func="main", file="recursive2.c",line="4"}] (gdb) Show frames between LOW_FRAME and HIGH_FRAME: (gdb) -stack-list-frames 3 5 ^done,stack= [frame={level="3 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="4 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}, frame={level="5 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}] (gdb) Show a single frame: (gdb) -stack-list-frames 3 3 ^done,stack= [frame={level="3 ",addr="0x000107a4",func="foo", file="recursive2.c",line="14"}] (gdb) The `-stack-list-locals' Command -------------------------------- Synopsis ........ -stack-list-locals PRINT-VALUES Display the local variable names for the current frame. With an argument of 0 prints only the names of the variables, with argument of 1 prints also their values. GDB Command ........... `info locals' in GDB, `gdb_get_locals' in `gdbtk'. Example ....... (gdb) -stack-list-locals 0 ^done,locals=[name="A",name="B",name="C"] (gdb) -stack-list-locals 1 ^done,locals=[{name="A",value="1"},{name="B",value="2"}, {name="C",value="3"}] (gdb) The `-stack-select-frame' Command --------------------------------- Synopsis ........ -stack-select-frame FRAMENUM Change the current frame. Select a different frame FRAMENUM on the stack. GDB Command ........... The corresponding GDB commands are `frame', `up', `down', `select-frame', `up-silent', and `down-silent'. Example ....... (gdb) -stack-select-frame 2 ^done (gdb)  File: gdb.info, Node: GDB/MI Symbol Query, Next: GDB/MI Target Manipulation, Prev: GDB/MI Stack Manipulation, Up: GDB/MI GDB/MI Symbol Query Commands ============================ The `-symbol-info-address' Command ---------------------------------- Synopsis ........ -symbol-info-address SYMBOL Describe where SYMBOL is stored. GDB Command ........... The corresponding GDB command is `info address'. Example ....... N.A. The `-symbol-info-file' Command ------------------------------- Synopsis ........ -symbol-info-file Show the file for the symbol. GDB Command ........... There's no equivalent GDB command. `gdbtk' has `gdb_find_file'. Example ....... N.A. The `-symbol-info-function' Command ----------------------------------- Synopsis ........ -symbol-info-function Show which function the symbol lives in. GDB Command ........... `gdb_get_function' in `gdbtk'. Example ....... N.A. The `-symbol-info-line' Command ------------------------------- Synopsis ........ -symbol-info-line Show the core addresses of the code for a source line. GDB Command ........... The corresponding GDB comamnd is `info line'. `gdbtk' has the `gdb_get_line' and `gdb_get_file' commands. Example ....... N.A. The `-symbol-info-symbol' Command --------------------------------- Synopsis ........ -symbol-info-symbol ADDR Describe what symbol is at location ADDR. GDB Command ........... The corresponding GDB command is `info symbol'. Example ....... N.A. The `-symbol-list-functions' Command ------------------------------------ Synopsis ........ -symbol-list-functions List the functions in the executable. GDB Command ........... `info functions' in GDB, `gdb_listfunc' and `gdb_search' in `gdbtk'. Example ....... N.A. The `-symbol-list-types' Command -------------------------------- Synopsis ........ -symbol-list-types List all the type names. GDB Command ........... The corresponding commands are `info types' in GDB, `gdb_search' in `gdbtk'. Example ....... N.A. The `-symbol-list-variables' Command ------------------------------------ Synopsis ........ -symbol-list-variables List all the global and static variable names. GDB Command ........... `info variables' in GDB, `gdb_search' in `gdbtk'. Example ....... N.A. The `-symbol-locate' Command ---------------------------- Synopsis ........ -symbol-locate GDB Command ........... `gdb_loc' in `gdbtk'. Example ....... N.A. The `-symbol-type' Command -------------------------- Synopsis ........ -symbol-type VARIABLE Show type of VARIABLE. GDB Command ........... The corresponding GDB command is `ptype', `gdbtk' has `gdb_obj_variable'. Example ....... N.A.  File: gdb.info, Node: GDB/MI Target Manipulation, Next: GDB/MI Thread Commands, Prev: GDB/MI Symbol Query, Up: GDB/MI GDB/MI Target Manipulation Commands =================================== The `-target-attach' Command ---------------------------- Synopsis ........ -target-attach PID | FILE Attach to a process PID or a file FILE outside of GDB. GDB command ........... The corresponding GDB command is `attach'. Example ....... N.A. The `-target-compare-sections' Command -------------------------------------- Synopsis ........ -target-compare-sections [ SECTION ] Compare data of section SECTION on target to the exec file. Without the argument, all sections are compared. GDB Command ........... The GDB equivalent is `compare-sections'. Example ....... N.A. The `-target-detach' Command ---------------------------- Synopsis ........ -target-detach Disconnect from the remote target. There's no output. GDB command ........... The corresponding GDB command is `detach'. Example ....... (gdb) -target-detach ^done (gdb) The `-target-download' Command ------------------------------ Synopsis ........ -target-download Loads the executable onto the remote target. It prints out an update message every half second, which includes the fields: `section' The name of the section. `section-sent' The size of what has been sent so far for that section. `section-size' The size of the section. `total-sent' The total size of what was sent so far (the current and the previous sections). `total-size' The size of the overall executable to download. Each message is sent as status record (*note GDB/MI Output Syntax: GDB/MI Output Syntax.). In addition, it prints the name and size of the sections, as they are downloaded. These messages include the following fields: `section' The name of the section. `section-size' The size of the section. `total-size' The size of the overall executable to download. At the end, a summary is printed. GDB Command ........... The corresponding GDB command is `load'. Example ....... Note: each status message appears on a single line. Here the messages have been broken down so that they can fit onto a page. (gdb) -target-download +download,{section=".text",section-size="6668",total-size="9880"} +download,{section=".text",section-sent="512",section-size="6668", total-sent="512",total-size="9880"} +download,{section=".text",section-sent="1024",section-size="6668", total-sent="1024",total-size="9880"} +download,{section=".text",section-sent="1536",section-size="6668", total-sent="1536",total-size="9880"} +download,{section=".text",section-sent="2048",section-size="6668", total-sent="2048",total-size="9880"} +download,{section=".text",section-sent="2560",section-size="6668", total-sent="2560",total-size="9880"} +download,{section=".text",section-sent="3072",section-size="6668", total-sent="3072",total-size="9880"} +download,{section=".text",section-sent="3584",section-size="6668", total-sent="3584",total-size="9880"} +download,{section=".text",section-sent="4096",section-size="6668", total-sent="4096",total-size="9880"} +download,{section=".text",section-sent="4608",section-size="6668", total-sent="4608",total-size="9880"} +download,{section=".text",section-sent="5120",section-size="6668", total-sent="5120",total-size="9880"} +download,{section=".text",section-sent="5632",section-size="6668", total-sent="5632",total-size="9880"} +download,{section=".text",section-sent="6144",section-size="6668", total-sent="6144",total-size="9880"} +download,{section=".text",section-sent="6656",section-size="6668", total-sent="6656",total-size="9880"} +download,{section=".init",section-size="28",total-size="9880"} +download,{section=".fini",section-size="28",total-size="9880"} +download,{section=".data",section-size="3156",total-size="9880"} +download,{section=".data",section-sent="512",section-size="3156", total-sent="7236",total-size="9880"} +download,{section=".data",section-sent="1024",section-size="3156", total-sent="7748",total-size="9880"} +download,{section=".data",section-sent="1536",section-size="3156", total-sent="8260",total-size="9880"} +download,{section=".data",section-sent="2048",section-size="3156", total-sent="8772",total-size="9880"} +download,{section=".data",section-sent="2560",section-size="3156", total-sent="9284",total-size="9880"} +download,{section=".data",section-sent="3072",section-size="3156", total-sent="9796",total-size="9880"} ^done,address="0x10004",load-size="9880",transfer-rate="6586", write-rate="429" (gdb) The `-target-exec-status' Command --------------------------------- Synopsis ........ -target-exec-status Provide information on the state of the target (whether it is running or not, for instance). GDB Command ........... There's no equivalent GDB command. Example ....... N.A. The `-target-list-available-targets' Command -------------------------------------------- Synopsis ........ -target-list-available-targets List the possible targets to connect to. GDB Command ........... The corresponding GDB command is `help target'. Example ....... N.A. The `-target-list-current-targets' Command ------------------------------------------ Synopsis ........ -target-list-current-targets Describe the current target. GDB Command ........... The corresponding information is printed by `info file' (among other things). Example ....... N.A. The `-target-list-parameters' Command ------------------------------------- Synopsis ........ -target-list-parameters GDB Command ........... No equivalent. Example ....... N.A. The `-target-select' Command ---------------------------- Synopsis ........ -target-select TYPE PARAMETERS ... Connect GDB to the remote target. This command takes two args: `TYPE' The type of target, for instance `async', `remote', etc. `PARAMETERS' Device names, host names and the like. *Note Commands for managing targets: Target Commands, for more details. The output is a connection notification, followed by the address at which the target program is, in the following form: ^connected,addr="ADDRESS",func="FUNCTION NAME", args=[ARG LIST] GDB Command ........... The corresponding GDB command is `target'. Example ....... (gdb) -target-select async /dev/ttya ^connected,addr="0xfe00a300",func="??",args=[] (gdb)  File: gdb.info, Node: GDB/MI Thread Commands, Next: GDB/MI Tracepoint Commands, Prev: GDB/MI Target Manipulation, Up: GDB/MI GDB/MI Thread Commands ====================== The `-thread-info' Command -------------------------- Synopsis ........ -thread-info GDB command ........... No equivalent. Example ....... N.A. The `-thread-list-all-threads' Command -------------------------------------- Synopsis ........ -thread-list-all-threads GDB Command ........... The equivalent GDB command is `info threads'. Example ....... N.A. The `-thread-list-ids' Command ------------------------------ Synopsis ........ -thread-list-ids Produces a list of the currently known GDB thread ids. At the end of the list it also prints the total number of such threads. GDB Command ........... Part of `info threads' supplies the same information. Example ....... No threads present, besides the main process: (gdb) -thread-list-ids ^done,thread-ids={},number-of-threads="0" (gdb) Several threads: (gdb) -thread-list-ids ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"}, number-of-threads="3" (gdb) The `-thread-select' Command ---------------------------- Synopsis ........ -thread-select THREADNUM Make THREADNUM the current thread. It prints the number of the new current thread, and the topmost frame for that thread. GDB Command ........... The corresponding GDB command is `thread'. Example ....... (gdb) -exec-next ^running (gdb) *stopped,reason="end-stepping-range",thread-id="2",line="187", file="../../../devo/gdb/testsuite/gdb.threads/linux-dp.c" (gdb) -thread-list-ids ^done, thread-ids={thread-id="3",thread-id="2",thread-id="1"}, number-of-threads="3" (gdb) -thread-select 3 ^done,new-thread-id="3", frame={level="0 ",func="vprintf", args=[{name="format",value="0x8048e9c \"%*s%c %d %c\\n\""}, {name="arg",value="0x2"}],file="vprintf.c",line="31"} (gdb)  File: gdb.info, Node: GDB/MI Tracepoint Commands, Next: GDB/MI Variable Objects, Prev: GDB/MI Thread Commands, Up: GDB/MI GDB/MI Tracepoint Commands ========================== The tracepoint commands are not yet implemented.  File: gdb.info, Node: GDB/MI Variable Objects, Prev: GDB/MI Tracepoint Commands, Up: GDB/MI GDB/MI Variable Objects ======================= Motivation for Variable Objects in GDB/MI ----------------------------------------- For the implementation of a variable debugger window (locals, watched expressions, etc.), we are proposing the adaptation of the existing code used by `Insight'. The two main reasons for that are: 1. It has been proven in practice (it is already on its second generation). 2. It will shorten development time (needless to say how important it is now). The original interface was designed to be used by Tcl code, so it was slightly changed so it could be used through GDB/MI. This section describes the GDB/MI operations that will be available and gives some hints about their use. _Note_: In addition to the set of operations described here, we expect the GUI implementation of a variable window to require, at least, the following operations: * `-gdb-show' `output-radix' * `-stack-list-arguments' * `-stack-list-locals' * `-stack-select-frame' Introduction to Variable Objects in GDB/MI ------------------------------------------ The basic idea behind variable objects is the creation of a named object to represent a variable, an expression, a memory location or even a CPU register. For each object created, a set of operations is available for examining or changing its properties. Furthermore, complex data types, such as C structures, are represented in a tree format. For instance, the `struct' type variable is the root and the children will represent the struct members. If a child is itself of a complex type, it will also have children of its own. Appropriate language differences are handled for C, C++ and Java. When returning the actual values of the objects, this facility allows for the individual selection of the display format used in the result creation. It can be chosen among: binary, decimal, hexadecimal, octal and natural. Natural refers to a default format automatically chosen based on the variable type (like decimal for an `int', hex for pointers, etc.). The following is the complete set of GDB/MI operations defined to access this functionality: *Operation* *Description* `-var-create' create a variable object `-var-delete' delete the variable object and its children `-var-set-format' set the display format of this variable `-var-show-format' show the display format of this variable `-var-info-num-children' tells how many children this object has `-var-list-children' return a list of the object's children `-var-info-type' show the type of this variable object `-var-info-expression' print what this variable object represents `-var-show-attributes' is this variable editable? does it exist here? `-var-evaluate-expression' get the value of this variable `-var-assign' set the value of this variable `-var-update' update the variable and its children In the next subsection we describe each operation in detail and suggest how it can be used. Description And Use of Operations on Variable Objects ----------------------------------------------------- The `-var-create' Command ------------------------- Synopsis ........ -var-create {NAME | "-"} {FRAME-ADDR | "*"} EXPRESSION This operation creates a variable object, which allows the monitoring of a variable, the result of an expression, a memory cell or a CPU register. The NAME parameter is the string by which the object can be referenced. It must be unique. If `-' is specified, the varobj system will generate a string "varNNNNNN" automatically. It will be unique provided that one does not specify NAME on that format. The command fails if a duplicate name is found. The frame under which the expression should be evaluated can be specified by FRAME-ADDR. A `*' indicates that the current frame should be used. EXPRESSION is any expression valid on the current language set (must not begin with a `*'), or one of the following: * `*ADDR', where ADDR is the address of a memory cell * `*ADDR-ADDR' -- a memory address range (TBD) * `$REGNAME' -- a CPU register name Result ...... This operation returns the name, number of children and the type of the object created. Type is returned as a string as the ones generated by the GDB CLI: name="NAME",numchild="N",type="TYPE" The `-var-delete' Command ------------------------- Synopsis ........ -var-delete NAME Deletes a previously created variable object and all of its children. Returns an error if the object NAME is not found. The `-var-set-format' Command ----------------------------- Synopsis ........ -var-set-format NAME FORMAT-SPEC Sets the output format for the value of the object NAME to be FORMAT-SPEC. The syntax for the FORMAT-SPEC is as follows: FORMAT-SPEC ==> {binary | decimal | hexadecimal | octal | natural} The `-var-show-format' Command ------------------------------ Synopsis ........ -var-show-format NAME Returns the format used to display the value of the object NAME. FORMAT ==> FORMAT-SPEC The `-var-info-num-children' Command ------------------------------------ Synopsis ........ -var-info-num-children NAME Returns the number of children of a variable object NAME: numchild=N The `-var-list-children' Command -------------------------------- Synopsis ........ -var-list-children NAME Returns a list of the children of the specified variable object: numchild=N,children={{name=NAME, numchild=N,type=TYPE},(repeats N times)} The `-var-info-type' Command ---------------------------- Synopsis ........ -var-info-type NAME Returns the type of the specified variable NAME. The type is returned as a string in the same format as it is output by the GDB CLI: type=TYPENAME The `-var-info-expression' Command ---------------------------------- Synopsis ........ -var-info-expression NAME Returns what is represented by the variable object NAME: lang=LANG-SPEC,exp=EXPRESSION where LANG-SPEC is `{"C" | "C++" | "Java"}'. The `-var-show-attributes' Command ---------------------------------- Synopsis ........ -var-show-attributes NAME List attributes of the specified variable object NAME: status=ATTR [ ( ,ATTR )* ] where ATTR is `{ { editable | noneditable } | TBD }'. The `-var-evaluate-expression' Command -------------------------------------- Synopsis ........ -var-evaluate-expression NAME Evaluates the expression that is represented by the specified variable object and returns its value as a string in the current format specified for the object: value=VALUE The `-var-assign' Command ------------------------- Synopsis ........ -var-assign NAME EXPRESSION Assigns the value of EXPRESSION to the variable object specified by NAME. The object must be `editable'. The `-var-update' Command ------------------------- Synopsis ........ -var-update {NAME | "*"} Update the value of the variable object NAME by evaluating its expression after fetching all the new values from memory or registers. A `*' causes all existing variable objects to be updated.  File: gdb.info, Node: GDB Bugs, Next: Formatting Documentation, Prev: GDB/MI, Up: Top Reporting Bugs in GDB ********************* Your bug reports play an essential role in making GDB reliable. Reporting a bug may help you by bringing a solution to your problem, or it may not. But in any case the principal function of a bug report is to help the entire community by making the next version of GDB work better. Bug reports are your contribution to the maintenance of GDB. In order for a bug report to serve its purpose, you must include the information that enables us to fix the bug. * Menu: * Bug Criteria:: Have you found a bug? * Bug Reporting:: How to report bugs  File: gdb.info, Node: Bug Criteria, Next: Bug Reporting, Up: GDB Bugs Have you found a bug? ===================== If you are not sure whether you have found a bug, here are some guidelines: * If the debugger gets a fatal signal, for any input whatever, that is a GDB bug. Reliable debuggers never crash. * If GDB produces an error message for valid input, that is a bug. (Note that if you're cross debugging, the problem may also be somewhere in the connection to the target.) * If GDB does not produce an error message for invalid input, that is a bug. However, you should note that your idea of "invalid input" might be our idea of "an extension" or "support for traditional practice". * If you are an experienced user of debugging tools, your suggestions for improvement of GDB are welcome in any case.  File: gdb.info, Node: Bug Reporting, Prev: Bug Criteria, Up: GDB Bugs How to report bugs ================== A number of companies and individuals offer support for GNU products. If you obtained GDB from a support organization, we recommend you contact that organization first. You can find contact information for many support companies and individuals in the file `etc/SERVICE' in the GNU Emacs distribution. In any event, we also recommend that you send bug reports for GDB to this addresses: bug-gdb@gnu.org *Do not send bug reports to `info-gdb', or to `help-gdb', or to any newsgroups.* Most users of GDB do not want to receive bug reports. Those that do have arranged to receive `bug-gdb'. The mailing list `bug-gdb' has a newsgroup `gnu.gdb.bug' which serves as a repeater. The mailing list and the newsgroup carry exactly the same messages. Often people think of posting bug reports to the newsgroup instead of mailing them. This appears to work, but it has one problem which can be crucial: a newsgroup posting often lacks a mail path back to the sender. Thus, if we need to ask for more information, we may be unable to reach you. For this reason, it is better to send bug reports to the mailing list. As a last resort, send bug reports on paper to: GNU Debugger Bugs Free Software Foundation Inc. 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA The fundamental principle of reporting bugs usefully is this: *report all the facts*. If you are not sure whether to state a fact or leave it out, state it! Often people omit facts because they think they know what causes the problem and assume that some details do not matter. Thus, you might assume that the name of the variable you use in an example does not matter. Well, probably it does not, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the debugger into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful. Keep in mind that the purpose of a bug report is to enable us to fix the bug. It may be that the bug has been reported previously, but neither you nor we can know that unless your bug report is complete and self-contained. Sometimes people give a few sketchy facts and ask, "Does this ring a bell?" Those bug reports are useless, and we urge everyone to _refuse to respond to them_ except to chide the sender to report bugs properly. To enable us to fix the bug, you should include all these things: * The version of GDB. GDB announces it if you start with no arguments; you can also print it at any time using `show version'. Without this, we will not know whether there is any point in looking for the bug in the current version of GDB. * The type of machine you are using, and the operating system name and version number. * What compiler (and its version) was used to compile GDB--e.g. "gcc-2.8.1". * What compiler (and its version) was used to compile the program you are debugging--e.g. "gcc-2.8.1", or "HP92453-01 A.10.32.03 HP C Compiler". For GCC, you can say `gcc --version' to get this information; for other compilers, see the documentation for those compilers. * The command arguments you gave the compiler to compile your example and observe the bug. For example, did you use `-O'? To guarantee you will not omit something important, list them all. A copy of the Makefile (or the output from make) is sufficient. If we were to try to guess the arguments, we would probably guess wrong and then we might not encounter the bug. * A complete input script, and all necessary source files, that will reproduce the bug. * A description of what behavior you observe that you believe is incorrect. For example, "It gets a fatal signal." Of course, if the bug is that GDB gets a fatal signal, then we will certainly notice it. But if the bug is incorrect output, we might not notice unless it is glaringly wrong. You might as well not give us a chance to make a mistake. Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as, your copy of GDB is out of synch, or you have encountered a bug in the C library on your system. (This has happened!) Your copy might crash and ours would not. If you told us to expect a crash, then when ours fails to crash, we would know that the bug was not happening for us. If you had not told us to expect a crash, then we would not be able to draw any conclusion from our observations. * If you wish to suggest changes to the GDB source, send us context diffs. If you even discuss something in the GDB source, refer to it by context, not by line number. The line numbers in our development sources will not match those in your sources. Your line numbers would convey no useful information to us. Here are some things that are not necessary: * A description of the envelope of the bug. Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it. This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. We recommend that you save your time for something else. Of course, if you can find a simpler example to report _instead_ of the original one, that is a convenience for us. Errors in the output will be easier to spot, running under the debugger will take less time, and so on. However, simplification is not vital; if you do not want to do this, report the bug anyway and send us the entire test case you used. * A patch for the bug. A patch for the bug does help us if it is a good one. But do not omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all. Sometimes with a program as complicated as GDB it is very hard to construct an example that will make the program follow a certain path through the code. If you do not send us the example, we will not be able to construct one, so we will not be able to verify that the bug is fixed. And if we cannot understand what bug you are trying to fix, or why your patch should be an improvement, we will not install it. A test case will help us to understand. * A guess about what the bug is or what it depends on. Such guesses are usually wrong. Even we cannot guess right about such things without first using the debugger to find the facts.