📄 c-debugger5.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Debugger </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-debugger.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-debugger4.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-debugger6.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="85154">8.5 Using the Debugger Command Line</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85156"> </a>The Tornado graphical interface is usually the most convenient way to run the debugger. However, you can also use the GDB command-line interface, which in some cases is the best way to perform a particular action (see <a href="c-debugger2.html#90692">Figure 8-1</a>). The debugger command-line window provides full access to GDB commands, as well as to Tornado extensions to those commands. The command line can be displayed with <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Debug</font></b>><b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Debug Windows</font></b>><b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Debug Command Line</font></b>. </p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="92002"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a>The command line drop-down list displays a history of all commands the user has entered. Commands can be selected from the list to be executed again. </div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout><dl class="margin"><dd><p class="Body"><a name="85160"> </a>The following sections summarize some particularly useful commands, and describe commands added by Wind River Systems that are not part of other versions of GDB.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="85162">8.5.1 GDB Initialization Files</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85163"> </a>One use of the debugger window is to experiment with text-based commands for actions that you might want to perform automatically each time you start debugging.</p><dd><p class="Body"><a name="85165"> </a>When the debugger first executes GDB, it looks for a file named <b class="file">.gdbinit</b>. It first looks in the directory named by the environment variable <b class="symbol_UC">HOME</b> (if it is defined), then in your current working directory.<sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup> If it finds the file in either directory, the debugger commands in it are executed; if it finds the file in both directories, the commands in both are executed. </p><dd><p class="Body"><a name="85170"> </a>A related initialization file, called <b class="file">gdb.tcl</b>, is specifically intended for Tcl code to customize GDB with your own extensions. The Tcl code in this file executes before <b class="file">.gdbinit</b>. The debugger searches for <b class="file">gdb.tcl</b> in two places: first in <b class="file">c:\tornado\.wind</b>, then (if the environment variable <b class="symbol_UC">HOME</b> is defined) in <b class="operator">%</b><b class="symbol_UC">HOME</b><b class="operator">%</b><b class="file">\.wind</b>. See <a href="c-debugger7.html#85425"><i class="title">8.7 Tcl: Debugger Automation</i></a> for a discussion of extending GDB through Tcl. See also <a href="c-debugger8.html#85604"><i class="title">8.8.1 Tcl: Debugger Initialization Files</i></a> for a discussion of how the Tornado debugger initialization files interact.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="85178">8.5.2 Selecting Modules to Debug</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85179"> </a>You can use the following commands to establish the debugging context:</p></dl><dl class="margin"><dd><div class="Item"><a name="85180"> </a><b class="command">add-symbol-file</b> <i class="textVariable">filename</i> </div><dl class="margin"><dd><div class="Indent"><a name="85182"> </a>Specifies an object file on the host for the debugging session. </div><br><dd><div class="Indent"><a name="85183"> </a>When the module you want to debug is already on the target (whether linked there statically, or downloaded by another Tornado tool), the debugger attempts to locate the corresponding object code on the host by querying the target server for the original file name and location. However, many factors often make it necessary to specify the object file explicitly. These factors include differing mount points on host and target, symbolic links, virtual file systems, or simply moving a file after downloading it. </div><br><dd><div class="Indent"><a name="85185"> </a>The debugger recognizes the abbreviation <b class="command">add</b> for this command.</div><br></dl><dd><div class="Item"><a name="85187"> </a><b class="command">load</b> <i class="textVariable">filename</i> </div><dl class="margin"><dd><div class="Indent"><a name="86084"> </a>Downloads an object file to the target.</div><br><dd><div class="Indent"><a name="85188"> </a>This command is equivalent to the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Download</font></b> command in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Debug</font></b> menu. You may sometimes find it preferable to invoke the command from the command panel--for example, when you can paste a complex path name from the clipboard instead of spending time in a file-browser interaction. </div><br></dl><dd><div class="Item"><a name="85189"> </a><b class="command">load</b> <i class="textVariable">filename serverFilename</i> </div><dl class="margin"><dd><div class="Indent"><a name="85190"> </a>Reads debugging information from <i class="textVariable">filename</i> while downloading <i class="textVariable">serverFilename</i> to the target.</div><br><dd><div class="Indent"><a name="85191"> </a>Use this version of the <b class="command">load</b> command when the target server you are using is on a host with a different view of the file system from your debugging session. For example, in some complex networks different hosts may mount the same file at different points: you may want to download a file <b class="file">c:\fred\applic.o</b> which your target server on another host sees as <b class="file">\\fredshost\fred\applic.o</b>.<sup><a href="#foot"><b class="FootnoteMarker">2</b></a></sup> </div><br><dd><div class="Indent"><a name="85198"> </a>Use the <i class="textVariable">serverFilename</i> argument to specify what file to download from the server's point of view. (You must also specify the <i class="textVariable">filename</i> argument from the local point of view for the benefit of the debugger itself.)</div><br><dd><div class="Indent"><a name="85202"> </a>See <a href="c-shell6.html#100857"><i class="title">6.6 Object Module Load Path</i></a> for a more extended discussion of the same problem in the context of the shell.</div><br></dl><dd><div class="Item"><a name="85204"> </a><b class="command">unload</b> <i class="textVariable">filename</i> </div><dl class="margin"><dd><div class="Indent"><a name="86089"> </a>Undoes the effect of <b class="command">load</b>: removes a dynamically linked file from the target, deletes its symbols from the debugger, and closes the file.</div><br></dl></dl><dl class="margin"><dd><p class="Body"><a name="85205"> </a>The <b class="command">load</b> and <b class="command">unload</b> commands both request confirmation if the debugger is attached to an active task. You can disable this confirmation request, as well as all other debugger confirmation requests, with <b class="command">set confirm</b>. See <i class="title">Debugging with GDB: Controlling GDB</i>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="85207">8.5.3 Running a Program</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85208"> </a>Just as with the Tornado shell, you can execute any subroutine in your application from the debugger. Use the following commands:</p></dl><dl class="margin"><dd><div class="Item"><a name="85210"> </a><b class="command">run</b> <i class="textVariable">routine</i> <i class="textVariable">args</i> </div><dl class="margin"><dd><div class="Indent"><a name="86091"> </a>This is the principal command to begin execution under debugger control. Execution begins at <i class="textVariable">routine</i>; you can specify an argument list after the routine name, with the arguments separated by spaces. The argument list may not contain floating-point or double-precision values. (This command is not available in system mode; use the shell to get tasks started in that mode. See <a href="c-shell2.html#91110"><i class="title">6.2.6 Using the Shell for System Mode Debugging</i></a>.)</div><br></dl><dd><div class="Item"><a name="85215"> </a><b class="command">call </b><i class="textVariable">expr</i> </div><dl class="margin"><dd><div class="Indent"><a name="86093"> </a>If a task is already running (and suspended, so that the debugger has control), you can evaluate any source-language expression (including subroutine calls) with the <b class="command">call</b> command. This provides a way of exploring the effects of other subroutines without abandoning the suspended call. Subroutine arguments in the expression <i class="textVariable">expr</i> may be of any type, including floating-point or double precision.</div><br></dl></dl><dl class="margin"><dd><p class="Body"><a name="85216"> </a>When you run a routine from the debugger using one of these commands, the routine runs until it encounters a breakpoint or a signal, or until it completes execution. The normal practice is to set one or more breakpoints in contexts of interest before starting a routine. However, you can interrupt the running task by clicking <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Interrupt Debugger</font></b> in the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Debug</font></b> menu or by pressing <kbd>CTRL+BREAK</kbd> from the <b class="guiLabel"><font face="Helvetica, sans-serif" size="-1" class="sans">Debugger</font></b> window. </p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="85217">8.5.4 Re-Setting Application I/O</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85219"> </a>By default, any tasks you start with the <b class="command">run</b> command use the standard I/O channels assigned globally in VxWorks. However, the debugger has the following mechanisms to specify input and output channels:</p><dl class="margin"><b class="BulletHead"><li><a name="85220"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Redirection with <b class="operator"><</b> and <b class="operator">></b></font></li></b></dl><dl class="margin"><dd><div class="Indent"><a name="85221"> </a>Each time you use the <b class="command">run</b> command, you can redirect I/O explicitly for that particular task by using <b class="operator"><</b> to redirect input and <b class="operator">></b> to redirect output. For output, ordinary path names refer to files on the host where the debugger is running, and path names preceded by an <b class="operator">@</b> character refer to files or devices on the target. Input cannot be redirected to host files, but input redirection to target files or devices is supported with the same @ convention for consistency. For example, the following command starts the routine <b class="routine"><i class="routine">appMain</i></b><b>( )</b> in a task that gets input from target device <b class="file">/tyCo/0</b> and writes output to host file <b class="file">grab.it</b>:</div><br></dl><dl class="margin"><dd><pre class="Code2"><b><a name="85222"></b><tt class="output">(gdb) </tt><b>run appMain > grab.it < @/tyCo/0</a></b></pre></dl><dl class="margin"><b class="BulletHead"><li><a name="85223"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">New Default I/O with tty Command</font></li></b></dl><dl class="margin"><dd><div class="Indent"><a name="85224"> </a>The debugger command <b class="command">tty</b> sets a new default input and output device for all future <b class="command">run</b> commands in the debugging session. The same convention used with explicit redirection on the <b class="command">run</b> line allow you to specify target files or devices for I/O. For example, the following command sets the default input and output channels to target device <b class="file">/tyCo/0</b>:</div><br></dl><dl class="margin"><dd><pre class="Code2"><b><a name="85225"></b><tt class="output">(gdb) </tt><b>tty @/tyCo/0</a></b></pre></dl><dl class="margin"><b class="BulletHead"><li><a name="85226"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Tcl: Redirection of Global or Task-Specific I/O</font></li></b></dl><dl class="margin"><dd><div class="Indent"><a name="85227"> </a>Tcl extensions are available within the debugger's Tcl interpreter to redirect either all target I/O, or the I/O channels of any running task. See <a href="c-debugger7.html#85499"><i class="title">8.7.3 Tcl: Invoking GDB Facilities</i></a> for details.</div><br></dl>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -