home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 9 / FreshFishVol9-CD2.bin / bbs / gnu / gdb-4.14-src.lha / gdb-4.14 / gdb / gdb.info-2 < prev    next >
Encoding:
GNU Info File  |  1995-03-04  |  49.6 KB  |  1,220 lines
  1. This is Info file ./gdb.info, produced by Makeinfo-1.55 from the input
  2. file gdb.texinfo.
  3.  
  4. START-INFO-DIR-ENTRY
  5. * Gdb: (gdb).                     The GNU debugger.
  6. END-INFO-DIR-ENTRY
  7.    This file documents the GNU debugger GDB.
  8.  
  9.    This is Edition 4.12, January 1994, of `Debugging with GDB: the GNU
  10. Source-Level Debugger' for GDB Version 4.14.
  11.  
  12.    Copyright (C) 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995 Free
  13. Software Foundation, Inc.
  14.  
  15.    Permission is granted to make and distribute verbatim copies of this
  16. manual provided the copyright notice and this permission notice are
  17. preserved on all copies.
  18.  
  19.    Permission is granted to copy and distribute modified versions of
  20. this manual under the conditions for verbatim copying, provided also
  21. that the entire resulting derived work is distributed under the terms
  22. of a permission notice identical to this one.
  23.  
  24.    Permission is granted to copy and distribute translations of this
  25. manual into another language, under the above conditions for modified
  26. versions.
  27.  
  28. 
  29. File: gdb.info,  Node: Input/Output,  Next: Attach,  Prev: Working Directory,  Up: Running
  30.  
  31. Your program's input and output
  32. ===============================
  33.  
  34.    By default, the program you run under GDB does input and output to
  35. the same terminal that GDB uses.  GDB switches the terminal to its own
  36. terminal modes to interact with you, but it records the terminal modes
  37. your program was using and switches back to them when you continue
  38. running your program.
  39.  
  40. `info terminal'
  41.      Displays information recorded by GDB about the terminal modes your
  42.      program is using.
  43.  
  44.    You can redirect your program's input and/or output using shell
  45. redirection with the `run' command.  For example,
  46.  
  47.      run > outfile
  48.  
  49. starts your program, diverting its output to the file `outfile'.
  50.  
  51.    Another way to specify where your program should do input and output
  52. is with the `tty' command.  This command accepts a file name as
  53. argument, and causes this file to be the default for future `run'
  54. commands.  It also resets the controlling terminal for the child
  55. process, for future `run' commands.  For example,
  56.  
  57.      tty /dev/ttyb
  58.  
  59. directs that processes started with subsequent `run' commands default
  60. to do input and output on the terminal `/dev/ttyb' and have that as
  61. their controlling terminal.
  62.  
  63.    An explicit redirection in `run' overrides the `tty' command's
  64. effect on the input/output device, but not its effect on the controlling
  65. terminal.
  66.  
  67.    When you use the `tty' command or redirect input in the `run'
  68. command, only the input *for your program* is affected.  The input for
  69. GDB still comes from your terminal.
  70.  
  71. 
  72. File: gdb.info,  Node: Attach,  Next: Kill Process,  Prev: Input/Output,  Up: Running
  73.  
  74. Debugging an already-running process
  75. ====================================
  76.  
  77. `attach PROCESS-ID'
  78.      This command attaches to a running process--one that was started
  79.      outside GDB.  (`info files' shows your active targets.)  The
  80.      command takes as argument a process ID.  The usual way to find out
  81.      the process-id of a Unix process is with the `ps' utility, or with
  82.      the `jobs -l' shell command.
  83.  
  84.      `attach' does not repeat if you press RET a second time after
  85.      executing the command.
  86.  
  87.    To use `attach', your program must be running in an environment
  88. which supports processes; for example, `attach' does not work for
  89. programs on bare-board targets that lack an operating system.  You must
  90. also have permission to send the process a signal.
  91.  
  92.    When using `attach', you should first use the `file' command to
  93. specify the program running in the process and load its symbol table.
  94. *Note Commands to Specify Files: Files.
  95.  
  96.    The first thing GDB does after arranging to debug the specified
  97. process is to stop it.  You can examine and modify an attached process
  98. with all the GDB commands that are ordinarily available when you start
  99. processes with `run'.  You can insert breakpoints; you can step and
  100. continue; you can modify storage.  If you would rather the process
  101. continue running, you may use the `continue' command after attaching
  102. GDB to the process.
  103.  
  104. `detach'
  105.      When you have finished debugging the attached process, you can use
  106.      the `detach' command to release it from GDB control.  Detaching
  107.      the process continues its execution.  After the `detach' command,
  108.      that process and GDB become completely independent once more, and
  109.      you are ready to `attach' another process or start one with `run'.
  110.      `detach' does not repeat if you press RET again after executing
  111.      the command.
  112.  
  113.    If you exit GDB or use the `run' command while you have an attached
  114. process, you kill that process.  By default, GDB asks for confirmation
  115. if you try to do either of these things; you can control whether or not
  116. you need to confirm by using the `set confirm' command (*note Optional
  117. warnings and messages: Messages/Warnings.).
  118.  
  119. 
  120. File: gdb.info,  Node: Kill Process,  Next: Process Information,  Prev: Attach,  Up: Running
  121.  
  122. Killing the child process
  123. =========================
  124.  
  125. `kill'
  126.      Kill the child process in which your program is running under GDB.
  127.  
  128.    This command is useful if you wish to debug a core dump instead of a
  129. running process.  GDB ignores any core dump file while your program is
  130. running.
  131.  
  132.    On some operating systems, a program cannot be executed outside GDB
  133. while you have breakpoints set on it inside GDB.  You can use the
  134. `kill' command in this situation to permit running your program outside
  135. the debugger.
  136.  
  137.    The `kill' command is also useful if you wish to recompile and
  138. relink your program, since on many systems it is impossible to modify an
  139. executable file while it is running in a process.  In this case, when
  140. you next type `run', GDB notices that the file has changed, and reads
  141. the symbol table again (while trying to preserve your current
  142. breakpoint settings).
  143.  
  144. 
  145. File: gdb.info,  Node: Process Information,  Next: Threads,  Prev: Kill Process,  Up: Running
  146.  
  147. Additional process information
  148. ==============================
  149.  
  150.    Some operating systems provide a facility called `/proc' that can be
  151. used to examine the image of a running process using file-system
  152. subroutines.  If GDB is configured for an operating system with this
  153. facility, the command `info proc' is available to report on several
  154. kinds of information about the process running your program.
  155.  
  156. `info proc'
  157.      Summarize available information about the process.
  158.  
  159. `info proc mappings'
  160.      Report on the address ranges accessible in the program, with
  161.      information on whether your program may read, write, or execute
  162.      each range.
  163.  
  164. `info proc times'
  165.      Starting time, user CPU time, and system CPU time for your program
  166.      and its children.
  167.  
  168. `info proc id'
  169.      Report on the process IDs related to your program: its own process
  170.      ID, the ID of its parent, the process group ID, and the session ID.
  171.  
  172. `info proc status'
  173.      General information on the state of the process.  If the process is
  174.      stopped, this report includes the reason for stopping, and any
  175.      signal received.
  176.  
  177. `info proc all'
  178.      Show all the above information about the process.
  179.  
  180. 
  181. File: gdb.info,  Node: Threads,  Next: Processes,  Prev: Process Information,  Up: Running
  182.  
  183. Debugging programs with multiple threads
  184. ========================================
  185.  
  186.    In some operating systems, a single program may have more than one
  187. "thread" of execution.  The precise semantics of threads differ from
  188. one operating system to another, but in general the threads of a single
  189. program are akin to multiple processes--except that they share one
  190. address space (that is, they can all examine and modify the same
  191. variables).  On the other hand, each thread has its own registers and
  192. execution stack, and perhaps private memory.
  193.  
  194.    GDB provides these facilities for debugging multi-thread programs:
  195.  
  196.    * automatic notification of new threads
  197.  
  198.    * `thread THREADNO', a command to switch among threads
  199.  
  200.    * `info threads', a command to inquire about existing threads
  201.  
  202.    * thread-specific breakpoints
  203.  
  204.      *Warning:* These facilities are not yet available on every GDB
  205.      configuration where the operating system supports threads.  If
  206.      your GDB does not support threads, these commands have no effect.
  207.      For example, a system without thread support shows no output from
  208.      `info threads', and always rejects the `thread' command, like this:
  209.  
  210.           (gdb) info threads
  211.           (gdb) thread 1
  212.           Thread ID 1 not known.  Use the "info threads" command to
  213.           see the IDs of currently known threads.
  214.  
  215.    The GDB thread debugging facility allows you to observe all threads
  216. while your program runs--but whenever GDB takes control, one thread in
  217. particular is always the focus of debugging.  This thread is called the
  218. "current thread".  Debugging commands show program information from the
  219. perspective of the current thread.
  220.  
  221.    Whenever GDB detects a new thread in your program, it displays the
  222. target system's identification for the thread with a message in the
  223. form `[New SYSTAG]'.  SYSTAG is a thread identifier whose form varies
  224. depending on the particular system.  For example, on LynxOS, you might
  225. see
  226.  
  227.      [New process 35 thread 27]
  228.  
  229. when GDB notices a new thread.  In contrast, on an SGI system, the
  230. SYSTAG is simply something like `process 368', with no further
  231. qualifier.
  232.  
  233.    For debugging purposes, GDB associates its own thread number--always
  234. a single integer--with each thread in your program.
  235.  
  236. `info threads'
  237.      Display a summary of all threads currently in your program.  GDB
  238.      displays for each thread (in this order):
  239.  
  240.        1. the thread number assigned by GDB
  241.  
  242.        2. the target system's thread identifier (SYSTAG)
  243.  
  244.        3. the current stack frame summary for that thread
  245.  
  246.      An asterisk `*' to the left of the GDB thread number indicates the
  247.      current thread.
  248.  
  249.      For example,
  250.  
  251.      (gdb) info threads
  252.        3 process 35 thread 27  0x34e5 in sigpause ()
  253.        2 process 35 thread 23  0x34e5 in sigpause ()
  254.      * 1 process 35 thread 13  main (argc=1, argv=0x7ffffff8)
  255.          at threadtest.c:68
  256.  
  257. `thread THREADNO'
  258.      Make thread number THREADNO the current thread.  The command
  259.      argument THREADNO is the internal GDB thread number, as shown in
  260.      the first field of the `info threads' display.  GDB responds by
  261.      displaying the system identifier of the thread you selected, and
  262.      its current stack frame summary:
  263.  
  264.           (gdb) thread 2
  265.           [Switching to process 35 thread 23]
  266.           0x34e5 in sigpause ()
  267.  
  268.      As with the `[New ...]' message, the form of the text after
  269.      `Switching to' depends on your system's conventions for identifying
  270.      threads.
  271.  
  272.    Whenever GDB stops your program, due to a breakpoint or a signal, it
  273. automatically selects the thread where that breakpoint or signal
  274. happened.  GDB alerts you to the context switch with a message of the
  275. form `[Switching to SYSTAG]' to identify the thread.
  276.  
  277.    *Note Stopping and starting multi-thread programs: Thread Stops, for
  278. more information about how GDB behaves when you stop and start programs
  279. with multiple threads.
  280.  
  281.    *Note Setting watchpoints: Set Watchpoints, for information about
  282. watchpoints in programs with multiple threads.
  283.  
  284. 
  285. File: gdb.info,  Node: Processes,  Prev: Threads,  Up: Running
  286.  
  287. Debugging programs with multiple processes
  288. ==========================================
  289.  
  290.    GDB has no special support for debugging programs which create
  291. additional processes using the `fork' function.  When a program forks,
  292. GDB will continue to debug the parent process and the child process
  293. will run unimpeded.  If you have set a breakpoint in any code which the
  294. child then executes, the child will get a `SIGTRAP' signal which
  295. (unless it catches the signal) will cause it to terminate.
  296.  
  297.    However, if you want to debug the child process there is a workaround
  298. which isn't too painful.  Put a call to `sleep' in the code which the
  299. child process executes after the fork.  It may be useful to sleep only
  300. if a certain environment variable is set, or a certain file exists, so
  301. that the delay need not occur when you don't want to run GDB on the
  302. child.  While the child is sleeping, use the `ps' program to get its
  303. process ID.  Then tell GDB (a new invocation of GDB if you are also
  304. debugging the parent process) to attach to the child process (see *Note
  305. Attach::).  From that point on you can debug the child process just
  306. like any other process which you attached to.
  307.  
  308. 
  309. File: gdb.info,  Node: Stopping,  Next: Stack,  Prev: Running,  Up: Top
  310.  
  311. Stopping and Continuing
  312. ***********************
  313.  
  314.    The principal purposes of using a debugger are so that you can stop
  315. your program before it terminates; or so that, if your program runs into
  316. trouble, you can investigate and find out why.
  317.  
  318.    Inside GDB, your program may stop for any of several reasons, such as
  319. a signal, a breakpoint, or reaching a new line after a GDB command such
  320. as `step'.  You may then examine and change variables, set new
  321. breakpoints or remove old ones, and then continue execution.  Usually,
  322. the messages shown by GDB provide ample explanation of the status of
  323. your program--but you can also explicitly request this information at
  324. any time.
  325.  
  326. `info program'
  327.      Display information about the status of your program: whether it is
  328.      running or not, what process it is, and why it stopped.
  329.  
  330. * Menu:
  331.  
  332.  
  333. * Breakpoints::                 Breakpoints, watchpoints, and exceptions
  334.  
  335. * Continuing and Stepping::     Resuming execution
  336.  
  337. * Signals::                     Signals
  338.  
  339. * Thread Stops::        Stopping and starting multi-thread programs
  340.  
  341. 
  342. File: gdb.info,  Node: Breakpoints,  Next: Continuing and Stepping,  Up: Stopping
  343.  
  344. Breakpoints, watchpoints, and exceptions
  345. ========================================
  346.  
  347.    A "breakpoint" makes your program stop whenever a certain point in
  348. the program is reached.  For each breakpoint, you can add conditions to
  349. control in finer detail whether your program stops.  You can set
  350. breakpoints with the `break' command and its variants (*note Setting
  351. breakpoints: Set Breaks.), to specify the place where your program
  352. should stop by line number, function name or exact address in the
  353. program.  In languages with exception handling (such as GNU C++), you
  354. can also set breakpoints where an exception is raised (*note
  355. Breakpoints and exceptions: Exception Handling.).
  356.  
  357.    A "watchpoint" is a special breakpoint that stops your program when
  358. the value of an expression changes.  You must use a different command
  359. to set watchpoints (*note Setting watchpoints: Set Watchpoints.), but
  360. aside from that, you can manage a watchpoint like any other breakpoint:
  361. you enable, disable, and delete both breakpoints and watchpoints using
  362. the same commands.
  363.  
  364.    You can arrange to have values from your program displayed
  365. automatically whenever GDB stops at a breakpoint.  *Note Automatic
  366. display: Auto Display.
  367.  
  368.    GDB assigns a number to each breakpoint or watchpoint when you
  369. create it; these numbers are successive integers starting with one.  In
  370. many of the commands for controlling various features of breakpoints you
  371. use the breakpoint number to say which breakpoint you want to change.
  372. Each breakpoint may be "enabled" or "disabled"; if disabled, it has no
  373. effect on your program until you enable it again.
  374.  
  375. * Menu:
  376.  
  377. * Set Breaks::                  Setting breakpoints
  378. * Set Watchpoints::             Setting watchpoints
  379.  
  380. * Exception Handling::          Breakpoints and exceptions
  381.  
  382. * Delete Breaks::               Deleting breakpoints
  383. * Disabling::                   Disabling breakpoints
  384. * Conditions::                  Break conditions
  385. * Break Commands::              Breakpoint command lists
  386.  
  387. * Breakpoint Menus::            Breakpoint menus
  388.  
  389. * Error in Breakpoints::        "Cannot insert breakpoints"
  390.  
  391. 
  392. File: gdb.info,  Node: Set Breaks,  Next: Set Watchpoints,  Up: Breakpoints
  393.  
  394. Setting breakpoints
  395. -------------------
  396.  
  397.    Breakpoints are set with the `break' command (abbreviated `b').  The
  398. debugger convenience variable `$bpnum' records the number of the
  399. beakpoint you've set most recently; see *Note Convenience variables:
  400. Convenience Vars, for a discussion of what you can do with convenience
  401. variables.
  402.  
  403.    You have several ways to say where the breakpoint should go.
  404.  
  405. `break FUNCTION'
  406.      Set a breakpoint at entry to function FUNCTION.  When using source
  407.      languages that permit overloading of symbols, such as C++,
  408.      FUNCTION may refer to more than one possible place to break.
  409.      *Note Breakpoint menus: Breakpoint Menus, for a discussion of that
  410.      situation.
  411.  
  412. `break +OFFSET'
  413. `break -OFFSET'
  414.      Set a breakpoint some number of lines forward or back from the
  415.      position at which execution stopped in the currently selected
  416.      frame.
  417.  
  418. `break LINENUM'
  419.      Set a breakpoint at line LINENUM in the current source file.  That
  420.      file is the last file whose source text was printed.  This
  421.      breakpoint stops your program just before it executes any of the
  422.      code on that line.
  423.  
  424. `break FILENAME:LINENUM'
  425.      Set a breakpoint at line LINENUM in source file FILENAME.
  426.  
  427. `break FILENAME:FUNCTION'
  428.      Set a breakpoint at entry to function FUNCTION found in file
  429.      FILENAME.  Specifying a file name as well as a function name is
  430.      superfluous except when multiple files contain similarly named
  431.      functions.
  432.  
  433. `break *ADDRESS'
  434.      Set a breakpoint at address ADDRESS.  You can use this to set
  435.      breakpoints in parts of your program which do not have debugging
  436.      information or source files.
  437.  
  438. `break'
  439.      When called without any arguments, `break' sets a breakpoint at
  440.      the next instruction to be executed in the selected stack frame
  441.      (*note Examining the Stack: Stack.).  In any selected frame but the
  442.      innermost, this makes your program stop as soon as control returns
  443.      to that frame.  This is similar to the effect of a `finish'
  444.      command in the frame inside the selected frame--except that
  445.      `finish' does not leave an active breakpoint.  If you use `break'
  446.      without an argument in the innermost frame, GDB stops the next
  447.      time it reaches the current location; this may be useful inside
  448.      loops.
  449.  
  450.      GDB normally ignores breakpoints when it resumes execution, until
  451.      at least one instruction has been executed.  If it did not do
  452.      this, you would be unable to proceed past a breakpoint without
  453.      first disabling the breakpoint.  This rule applies whether or not
  454.      the breakpoint already existed when your program stopped.
  455.  
  456. `break ... if COND'
  457.      Set a breakpoint with condition COND; evaluate the expression COND
  458.      each time the breakpoint is reached, and stop only if the value is
  459.      nonzero--that is, if COND evaluates as true.  `...' stands for one
  460.      of the possible arguments described above (or no argument)
  461.      specifying where to break.  *Note Break conditions: Conditions,
  462.      for more information on breakpoint conditions.
  463.  
  464. `tbreak ARGS'
  465.      Set a breakpoint enabled only for one stop.  ARGS are the same as
  466.      for the `break' command, and the breakpoint is set in the same
  467.      way, but the breakpoint is automatically deleted after the first
  468.      time your program stops there.  *Note Disabling breakpoints:
  469.      Disabling.
  470.  
  471. `rbreak REGEX'
  472.      Set breakpoints on all functions matching the regular expression
  473.      REGEX.  This command sets an unconditional breakpoint on all
  474.      matches, printing a list of all breakpoints it set.  Once these
  475.      breakpoints are set, they are treated just like the breakpoints
  476.      set with the `break' command.  You can delete them, disable them,
  477.      or make them conditional the same way as any other breakpoint.
  478.  
  479.      When debugging C++ programs, `rbreak' is useful for setting
  480.      breakpoints on overloaded functions that are not members of any
  481.      special classes.
  482.  
  483. `info breakpoints [N]'
  484. `info break [N]'
  485. `info watchpoints [N]'
  486.      Print a table of all breakpoints and watchpoints set and not
  487.      deleted, with the following columns for each breakpoint:
  488.  
  489.     *Breakpoint Numbers*
  490.     *Type*
  491.           Breakpoint or watchpoint.
  492.  
  493.     *Disposition*
  494.           Whether the breakpoint is marked to be disabled or deleted
  495.           when hit.
  496.  
  497.     *Enabled or Disabled*
  498.           Enabled breakpoints are marked with `y'.  `n' marks
  499.           breakpoints that are not enabled.
  500.  
  501.     *Address*
  502.           Where the breakpoint is in your program, as a memory address
  503.  
  504.     *What*
  505.           Where the breakpoint is in the source for your program, as a
  506.           file and line number.
  507.  
  508.      If a breakpoint is conditional, `info break' shows the condition on
  509.      the line following the affected breakpoint; breakpoint commands,
  510.      if any, are listed after that.
  511.  
  512.      `info break' with a breakpoint number N as argument lists only
  513.      that breakpoint.  The convenience variable `$_' and the default
  514.      examining-address for the `x' command are set to the address of
  515.      the last breakpoint listed (*note Examining memory: Memory.).
  516.  
  517.    GDB allows you to set any number of breakpoints at the same place in
  518. your program.  There is nothing silly or meaningless about this.  When
  519. the breakpoints are conditional, this is even useful (*note Break
  520. conditions: Conditions.).
  521.  
  522.    GDB itself sometimes sets breakpoints in your program for special
  523. purposes, such as proper handling of `longjmp' (in C programs).  These
  524. internal breakpoints are assigned negative numbers, starting with `-1';
  525. `info breakpoints' does not display them.
  526.  
  527.    You can see these breakpoints with the GDB maintenance command
  528. `maint info breakpoints'.
  529.  
  530. `maint info breakpoints'
  531.      Using the same format as `info breakpoints', display both the
  532.      breakpoints you've set explicitly, and those GDB is using for
  533.      internal purposes.  Internal breakpoints are shown with negative
  534.      breakpoint numbers.  The type column identifies what kind of
  535.      breakpoint is shown:
  536.  
  537.     `breakpoint'
  538.           Normal, explicitly set breakpoint.
  539.  
  540.     `watchpoint'
  541.           Normal, explicitly set watchpoint.
  542.  
  543.     `longjmp'
  544.           Internal breakpoint, used to handle correctly stepping through
  545.           `longjmp' calls.
  546.  
  547.     `longjmp resume'
  548.           Internal breakpoint at the target of a `longjmp'.
  549.  
  550.     `until'
  551.           Temporary internal breakpoint used by the GDB `until' command.
  552.  
  553.     `finish'
  554.           Temporary internal breakpoint used by the GDB `finish'
  555.           command.
  556.  
  557. 
  558. File: gdb.info,  Node: Set Watchpoints,  Next: Exception Handling,  Prev: Set Breaks,  Up: Breakpoints
  559.  
  560. Setting watchpoints
  561. -------------------
  562.  
  563.    You can use a watchpoint to stop execution whenever the value of an
  564. expression changes, without having to predict a particular place where
  565. this may happen.
  566.  
  567.    Watchpoints currently execute two orders of magnitude more slowly
  568. than other breakpoints, but this can be well worth it to catch errors
  569. where you have no clue what part of your program is the culprit.
  570.  
  571.    Some processors provide special hardware to support watchpoint
  572. evaluation; GDB will use such hardware if it is available, and if the
  573. support code has been added for that configuration.
  574.  
  575. `watch EXPR'
  576.      Set a watchpoint for an expression.
  577.  
  578. `info watchpoints'
  579.      This command prints a list of watchpoints and breakpoints; it is
  580.      the same as `info break'.
  581.  
  582.      *Warning:* in multi-thread programs, watchpoints have only limited
  583.      usefulness.  With the current watchpoint implementation, GDB can
  584.      only watch the value of an expression *in a single thread*.  If
  585.      you are confident that the expression can only change due to the
  586.      current thread's activity (and if you are also confident that no
  587.      other thread can become current), then you can use watchpoints as
  588.      usual.  However, GDB may not notice when a non-current thread's
  589.      activity changes the expression.
  590.  
  591. 
  592. File: gdb.info,  Node: Exception Handling,  Next: Delete Breaks,  Prev: Set Watchpoints,  Up: Breakpoints
  593.  
  594. Breakpoints and exceptions
  595. --------------------------
  596.  
  597.    Some languages, such as GNU C++, implement exception handling.  You
  598. can use GDB to examine what caused your program to raise an exception,
  599. and to list the exceptions your program is prepared to handle at a
  600. given point in time.
  601.  
  602. `catch EXCEPTIONS'
  603.      You can set breakpoints at active exception handlers by using the
  604.      `catch' command.  EXCEPTIONS is a list of names of exceptions to
  605.      catch.
  606.  
  607.    You can use `info catch' to list active exception handlers.  *Note
  608. Information about a frame: Frame Info.
  609.  
  610.    There are currently some limitations to exception handling in GDB:
  611.  
  612.    * If you call a function interactively, GDB normally returns control
  613.      to you when the function has finished executing.  If the call
  614.      raises an exception, however, the call may bypass the mechanism
  615.      that returns control to you and cause your program to simply
  616.      continue running until it hits a breakpoint, catches a signal that
  617.      GDB is listening for, or exits.
  618.  
  619.    * You cannot raise an exception interactively.
  620.  
  621.    * You cannot install an exception handler interactively.
  622.  
  623.    Sometimes `catch' is not the best way to debug exception handling:
  624. if you need to know exactly where an exception is raised, it is better
  625. to stop *before* the exception handler is called, since that way you
  626. can see the stack before any unwinding takes place.  If you set a
  627. breakpoint in an exception handler instead, it may not be easy to find
  628. out where the exception was raised.
  629.  
  630.    To stop just before an exception handler is called, you need some
  631. knowledge of the implementation.  In the case of GNU C++, exceptions are
  632. raised by calling a library function named `__raise_exception' which
  633. has the following ANSI C interface:
  634.  
  635.          /* ADDR is where the exception identifier is stored.
  636.             ID is the exception identifier.  */
  637.          void __raise_exception (void **ADDR, void *ID);
  638.  
  639. To make the debugger catch all exceptions before any stack unwinding
  640. takes place, set a breakpoint on `__raise_exception' (*note
  641. Breakpoints; watchpoints; and exceptions: Breakpoints.).
  642.  
  643.    With a conditional breakpoint (*note Break conditions: Conditions.)
  644. that depends on the value of ID, you can stop your program when a
  645. specific exception is raised.  You can use multiple conditional
  646. breakpoints to stop your program when any of a number of exceptions are
  647. raised.
  648.  
  649. 
  650. File: gdb.info,  Node: Delete Breaks,  Next: Disabling,  Prev: Exception Handling,  Up: Breakpoints
  651.  
  652. Deleting breakpoints
  653. --------------------
  654.  
  655.    It is often necessary to eliminate a breakpoint or watchpoint once it
  656. has done its job and you no longer want your program to stop there.
  657. This is called "deleting" the breakpoint.  A breakpoint that has been
  658. deleted no longer exists; it is forgotten.
  659.  
  660.    With the `clear' command you can delete breakpoints according to
  661. where they are in your program.  With the `delete' command you can
  662. delete individual breakpoints or watchpoints by specifying their
  663. breakpoint numbers.
  664.  
  665.    It is not necessary to delete a breakpoint to proceed past it.  GDB
  666. automatically ignores breakpoints on the first instruction to be
  667. executed when you continue execution without changing the execution
  668. address.
  669.  
  670. `clear'
  671.      Delete any breakpoints at the next instruction to be executed in
  672.      the selected stack frame (*note Selecting a frame: Selection.).
  673.      When the innermost frame is selected, this is a good way to delete
  674.      a breakpoint where your program just stopped.
  675.  
  676. `clear FUNCTION'
  677. `clear FILENAME:FUNCTION'
  678.      Delete any breakpoints set at entry to the function FUNCTION.
  679.  
  680. `clear LINENUM'
  681. `clear FILENAME:LINENUM'
  682.      Delete any breakpoints set at or within the code of the specified
  683.      line.
  684.  
  685. `delete [breakpoints] [BNUMS...]'
  686.      Delete the breakpoints or watchpoints of the numbers specified as
  687.      arguments.  If no argument is specified, delete all breakpoints
  688.      (GDB asks confirmation, unless you have `set confirm off').  You
  689.      can abbreviate this command as `d'.
  690.  
  691. 
  692. File: gdb.info,  Node: Disabling,  Next: Conditions,  Prev: Delete Breaks,  Up: Breakpoints
  693.  
  694. Disabling breakpoints
  695. ---------------------
  696.  
  697.    Rather than deleting a breakpoint or watchpoint, you might prefer to
  698. "disable" it.  This makes the breakpoint inoperative as if it had been
  699. deleted, but remembers the information on the breakpoint so that you
  700. can "enable" it again later.
  701.  
  702.    You disable and enable breakpoints and watchpoints with the `enable'
  703. and `disable' commands, optionally specifying one or more breakpoint
  704. numbers as arguments.  Use `info break' or `info watch' to print a list
  705. of breakpoints or watchpoints if you do not know which numbers to use.
  706.  
  707.    A breakpoint or watchpoint can have any of four different states of
  708. enablement:
  709.  
  710.    * Enabled.  The breakpoint stops your program.  A breakpoint set
  711.      with the `break' command starts out in this state.
  712.  
  713.    * Disabled.  The breakpoint has no effect on your program.
  714.  
  715.    * Enabled once.  The breakpoint stops your program, but then becomes
  716.      disabled.  A breakpoint set with the `tbreak' command starts out in
  717.      this state.
  718.  
  719.    * Enabled for deletion.  The breakpoint stops your program, but
  720.      immediately after it does so it is deleted permanently.
  721.  
  722.    You can use the following commands to enable or disable breakpoints
  723. and watchpoints:
  724.  
  725. `disable [breakpoints] [BNUMS...]'
  726.      Disable the specified breakpoints--or all breakpoints, if none are
  727.      listed.  A disabled breakpoint has no effect but is not forgotten.
  728.      All options such as ignore-counts, conditions and commands are
  729.      remembered in case the breakpoint is enabled again later.  You may
  730.      abbreviate `disable' as `dis'.
  731.  
  732. `enable [breakpoints] [BNUMS...]'
  733.      Enable the specified breakpoints (or all defined breakpoints).
  734.      They become effective once again in stopping your program.
  735.  
  736. `enable [breakpoints] once BNUMS...'
  737.      Enable the specified breakpoints temporarily.  GDB disables any of
  738.      these breakpoints immediately after stopping your program.
  739.  
  740. `enable [breakpoints] delete BNUMS...'
  741.      Enable the specified breakpoints to work once, then die.  GDB
  742.      deletes any of these breakpoints as soon as your program stops
  743.      there.
  744.  
  745.    Save for a breakpoint set with `tbreak' (*note Setting breakpoints:
  746. Set Breaks.), breakpoints that you set are initially enabled;
  747. subsequently, they become disabled or enabled only when you use one of
  748. the commands above.  (The command `until' can set and delete a
  749. breakpoint of its own, but it does not change the state of your other
  750. breakpoints; see *Note Continuing and stepping: Continuing and
  751. Stepping.)
  752.  
  753. 
  754. File: gdb.info,  Node: Conditions,  Next: Break Commands,  Prev: Disabling,  Up: Breakpoints
  755.  
  756. Break conditions
  757. ----------------
  758.  
  759.    The simplest sort of breakpoint breaks every time your program
  760. reaches a specified place.  You can also specify a "condition" for a
  761. breakpoint.  A condition is just a Boolean expression in your
  762. programming language (*note Expressions: Expressions.).  A breakpoint
  763. with a condition evaluates the expression each time your program
  764. reaches it, and your program stops only if the condition is *true*.
  765.  
  766.    This is the converse of using assertions for program validation; in
  767. that situation, you want to stop when the assertion is violated--that
  768. is, when the condition is false.  In C, if you want to test an
  769. assertion expressed by the condition ASSERT, you should set the
  770. condition `! ASSERT' on the appropriate breakpoint.
  771.  
  772.    Conditions are also accepted for watchpoints; you may not need them,
  773. since a watchpoint is inspecting the value of an expression anyhow--but
  774. it might be simpler, say, to just set a watchpoint on a variable name,
  775. and specify a condition that tests whether the new value is an
  776. interesting one.
  777.  
  778.    Break conditions can have side effects, and may even call functions
  779. in your program.  This can be useful, for example, to activate functions
  780. that log program progress, or to use your own print functions to format
  781. special data structures. The effects are completely predictable unless
  782. there is another enabled breakpoint at the same address.  (In that
  783. case, GDB might see the other breakpoint first and stop your program
  784. without checking the condition of this one.)  Note that breakpoint
  785. commands are usually more convenient and flexible for the purpose of
  786. performing side effects when a breakpoint is reached (*note Breakpoint
  787. command lists: Break Commands.).
  788.  
  789.    Break conditions can be specified when a breakpoint is set, by using
  790. `if' in the arguments to the `break' command.  *Note Setting
  791. breakpoints: Set Breaks.  They can also be changed at any time with the
  792. `condition' command.  The `watch' command does not recognize the `if'
  793. keyword; `condition' is the only way to impose a further condition on a
  794. watchpoint.
  795.  
  796. `condition BNUM EXPRESSION'
  797.      Specify EXPRESSION as the break condition for breakpoint or
  798.      watchpoint number BNUM.  After you set a condition, breakpoint
  799.      BNUM stops your program only if the value of EXPRESSION is true
  800.      (nonzero, in C).  When you use `condition', GDB checks EXPRESSION
  801.      immediately for syntactic correctness, and to determine whether
  802.      symbols in it have referents in the context of your breakpoint.
  803.      G{No Value For "DBN"} does not actually evaluate EXPRESSION at the
  804.      time the `condition' command is given, however.  *Note
  805.      Expressions: Expressions.
  806.  
  807. `condition BNUM'
  808.      Remove the condition from breakpoint number BNUM.  It becomes an
  809.      ordinary unconditional breakpoint.
  810.  
  811.    A special case of a breakpoint condition is to stop only when the
  812. breakpoint has been reached a certain number of times.  This is so
  813. useful that there is a special way to do it, using the "ignore count"
  814. of the breakpoint.  Every breakpoint has an ignore count, which is an
  815. integer.  Most of the time, the ignore count is zero, and therefore has
  816. no effect.  But if your program reaches a breakpoint whose ignore count
  817. is positive, then instead of stopping, it just decrements the ignore
  818. count by one and continues.  As a result, if the ignore count value is
  819. N, the breakpoint does not stop the next N times your program reaches
  820. it.
  821.  
  822. `ignore BNUM COUNT'
  823.      Set the ignore count of breakpoint number BNUM to COUNT.  The next
  824.      COUNT times the breakpoint is reached, your program's execution
  825.      does not stop; other than to decrement the ignore count, GDB takes
  826.      no action.
  827.  
  828.      To make the breakpoint stop the next time it is reached, specify a
  829.      count of zero.
  830.  
  831.      When you use `continue' to resume execution of your program from a
  832.      breakpoint, you can specify an ignore count directly as an
  833.      argument to `continue', rather than using `ignore'.  *Note
  834.      Continuing and stepping: Continuing and Stepping.
  835.  
  836.      If a breakpoint has a positive ignore count and a condition, the
  837.      condition is not checked.  Once the ignore count reaches zero, GDB
  838.      resumes checking the condition.
  839.  
  840.      You could achieve the effect of the ignore count with a condition
  841.      such as `$foo-- <= 0' using a debugger convenience variable that
  842.      is decremented each time.  *Note Convenience variables:
  843.      Convenience Vars.
  844.  
  845. 
  846. File: gdb.info,  Node: Break Commands,  Next: Breakpoint Menus,  Prev: Conditions,  Up: Breakpoints
  847.  
  848. Breakpoint command lists
  849. ------------------------
  850.  
  851.    You can give any breakpoint (or watchpoint) a series of commands to
  852. execute when your program stops due to that breakpoint.  For example,
  853. you might want to print the values of certain expressions, or enable
  854. other breakpoints.
  855.  
  856. `commands [BNUM]'
  857. `... COMMAND-LIST ...'
  858. `end'
  859.      Specify a list of commands for breakpoint number BNUM.  The
  860.      commands themselves appear on the following lines.  Type a line
  861.      containing just `end' to terminate the commands.
  862.  
  863.      To remove all commands from a breakpoint, type `commands' and
  864.      follow it immediately with `end'; that is, give no commands.
  865.  
  866.      With no BNUM argument, `commands' refers to the last breakpoint or
  867.      watchpoint set (not to the breakpoint most recently encountered).
  868.  
  869.    Pressing RET as a means of repeating the last GDB command is
  870. disabled within a COMMAND-LIST.
  871.  
  872.    You can use breakpoint commands to start your program up again.
  873. Simply use the `continue' command, or `step', or any other command that
  874. resumes execution.
  875.  
  876.    Any other commands in the command list, after a command that resumes
  877. execution, are ignored.  This is because any time you resume execution
  878. (even with a simple `next' or `step'), you may encounter another
  879. breakpoint--which could have its own command list, leading to
  880. ambiguities about which list to execute.
  881.  
  882.    If the first command you specify in a command list is `silent', the
  883. usual message about stopping at a breakpoint is not printed.  This may
  884. be desirable for breakpoints that are to print a specific message and
  885. then continue.  If none of the remaining commands print anything, you
  886. see no sign that the breakpoint was reached.  `silent' is meaningful
  887. only at the beginning of a breakpoint command list.
  888.  
  889.    The commands `echo', `output', and `printf' allow you to print
  890. precisely controlled output, and are often useful in silent
  891. breakpoints.  *Note Commands for controlled output: Output.
  892.  
  893.    For example, here is how you could use breakpoint commands to print
  894. the value of `x' at entry to `foo' whenever `x' is positive.
  895.  
  896.      break foo if x>0
  897.      commands
  898.      silent
  899.      printf "x is %d\n",x
  900.      cont
  901.      end
  902.  
  903.    One application for breakpoint commands is to compensate for one bug
  904. so you can test for another.  Put a breakpoint just after the erroneous
  905. line of code, give it a condition to detect the case in which something
  906. erroneous has been done, and give it commands to assign correct values
  907. to any variables that need them.  End with the `continue' command so
  908. that your program does not stop, and start with the `silent' command so
  909. that no output is produced.  Here is an example:
  910.  
  911.      break 403
  912.      commands
  913.      silent
  914.      set x = y + 4
  915.      cont
  916.      end
  917.  
  918. 
  919. File: gdb.info,  Node: Breakpoint Menus,  Next: Error in Breakpoints,  Prev: Break Commands,  Up: Breakpoints
  920.  
  921. Breakpoint menus
  922. ----------------
  923.  
  924.    Some programming languages (notably C++) permit a single function
  925. name to be defined several times, for application in different contexts.
  926. This is called "overloading".  When a function name is overloaded,
  927. `break FUNCTION' is not enough to tell GDB where you want a breakpoint.
  928. If you realize this is a problem, you can use something like `break
  929. FUNCTION(TYPES)' to specify which particular version of the function
  930. you want.  Otherwise, GDB offers you a menu of numbered choices for
  931. different possible breakpoints, and waits for your selection with the
  932. prompt `>'.  The first two options are always `[0] cancel' and `[1]
  933. all'.  Typing `1' sets a breakpoint at each definition of FUNCTION, and
  934. typing `0' aborts the `break' command without setting any new
  935. breakpoints.
  936.  
  937.    For example, the following session excerpt shows an attempt to set a
  938. breakpoint at the overloaded symbol `String::after'.  We choose three
  939. particular definitions of that function name:
  940.  
  941.      (gdb) b String::after
  942.      [0] cancel
  943.      [1] all
  944.      [2] file:String.cc; line number:867
  945.      [3] file:String.cc; line number:860
  946.      [4] file:String.cc; line number:875
  947.      [5] file:String.cc; line number:853
  948.      [6] file:String.cc; line number:846
  949.      [7] file:String.cc; line number:735
  950.      > 2 4 6
  951.      Breakpoint 1 at 0xb26c: file String.cc, line 867.
  952.      Breakpoint 2 at 0xb344: file String.cc, line 875.
  953.      Breakpoint 3 at 0xafcc: file String.cc, line 846.
  954.      Multiple breakpoints were set.
  955.      Use the "delete" command to delete unwanted
  956.       breakpoints.
  957.      (gdb)
  958.  
  959. 
  960. File: gdb.info,  Node: Error in Breakpoints,  Prev: Breakpoint Menus,  Up: Breakpoints
  961.  
  962. "Cannot insert breakpoints"
  963. ---------------------------
  964.  
  965.    Under some operating systems, breakpoints cannot be used in a
  966. program if any other process is running that program.  In this
  967. situation, attempting to run or continue a program with a breakpoint
  968. causes GDB to stop the other process.
  969.  
  970.    When this happens, you have three ways to proceed:
  971.  
  972.   1. Remove or disable the breakpoints, then continue.
  973.  
  974.   2. Suspend GDB, and copy the file containing your program to a new
  975.      name.  Resume GDB and use the `exec-file' command to specify that
  976.      GDB should run your program under that name.  Then start your
  977.      program again.
  978.  
  979.   3. Relink your program so that the text segment is nonsharable, using
  980.      the linker option `-N'.  The operating system limitation may not
  981.      apply to nonsharable executables.
  982.  
  983. 
  984. File: gdb.info,  Node: Continuing and Stepping,  Next: Signals,  Prev: Breakpoints,  Up: Stopping
  985.  
  986. Continuing and stepping
  987. =======================
  988.  
  989.    "Continuing" means resuming program execution until your program
  990. completes normally.  In contrast, "stepping" means executing just one
  991. more "step" of your program, where "step" may mean either one line of
  992. source code, or one machine instruction (depending on what particular
  993. command you use).  Either when continuing or when stepping, your
  994. program may stop even sooner, due to a breakpoint or a signal.  (If due
  995. to a signal, you may want to use `handle', or use `signal 0' to resume
  996. execution.  *Note Signals: Signals.)
  997.  
  998. `continue [IGNORE-COUNT]'
  999. `c [IGNORE-COUNT]'
  1000. `fg [IGNORE-COUNT]'
  1001.      Resume program execution, at the address where your program last
  1002.      stopped; any breakpoints set at that address are bypassed.  The
  1003.      optional argument IGNORE-COUNT allows you to specify a further
  1004.      number of times to ignore a breakpoint at this location; its
  1005.      effect is like that of `ignore' (*note Break conditions:
  1006.      Conditions.).
  1007.  
  1008.      The argument IGNORE-COUNT is meaningful only when your program
  1009.      stopped due to a breakpoint.  At other times, the argument to
  1010.      `continue' is ignored.
  1011.  
  1012.      The synonyms `c' and `fg' are provided purely for convenience, and
  1013.      have exactly the same behavior as `continue'.
  1014.  
  1015.    To resume execution at a different place, you can use `return'
  1016. (*note Returning from a function: Returning.) to go back to the calling
  1017. function; or `jump' (*note Continuing at a different address: Jumping.)
  1018. to go to an arbitrary location in your program.
  1019.  
  1020.    A typical technique for using stepping is to set a breakpoint (*note
  1021. Breakpoints; watchpoints; and exceptions: Breakpoints.) at the
  1022. beginning of the function or the section of your program where a
  1023. problem is believed to lie, run your program until it stops at that
  1024. breakpoint, and then step through the suspect area, examining the
  1025. variables that are interesting, until you see the problem happen.
  1026.  
  1027. `step'
  1028.      Continue running your program until control reaches a different
  1029.      source line, then stop it and return control to GDB.  This command
  1030.      is abbreviated `s'.
  1031.  
  1032.           *Warning:* If you use the `step' command while control is
  1033.           within a function that was compiled without debugging
  1034.           information, execution proceeds until control reaches a
  1035.           function that does have debugging information.  Likewise, it
  1036.           will not step into a function which is compiled without
  1037.           debugging information.  To step through functions without
  1038.           debugging information, use the `stepi' command, described
  1039.           below.
  1040.  
  1041. `step COUNT'
  1042.      Continue running as in `step', but do so COUNT times.  If a
  1043.      breakpoint is reached, or a signal not related to stepping occurs
  1044.      before COUNT steps, stepping stops right away.
  1045.  
  1046. `next [COUNT]'
  1047.      Continue to the next source line in the current (innermost) stack
  1048.      frame.  Similar to `step', but any function calls appearing within
  1049.      the line of code are executed without stopping.  Execution stops
  1050.      when control reaches a different line of code at the stack level
  1051.      which was executing when the `next' command was given.  This
  1052.      command is abbreviated `n'.
  1053.  
  1054.      An argument COUNT is a repeat count, as for `step'.
  1055.  
  1056.      `next' within a function that lacks debugging information acts like
  1057.      `step', but any function calls appearing within the code of the
  1058.      function are executed without stopping.
  1059.  
  1060. `finish'
  1061.      Continue running until just after function in the selected stack
  1062.      frame returns.  Print the returned value (if any).
  1063.  
  1064.      Contrast this with the `return' command (*note Returning from a
  1065.      function: Returning.).
  1066.  
  1067. `until'
  1068. `u'
  1069.      Continue running until a source line past the current line, in the
  1070.      current stack frame, is reached.  This command is used to avoid
  1071.      single stepping through a loop more than once.  It is like the
  1072.      `next' command, except that when `until' encounters a jump, it
  1073.      automatically continues execution until the program counter is
  1074.      greater than the address of the jump.
  1075.  
  1076.      This means that when you reach the end of a loop after single
  1077.      stepping though it, `until' makes your program continue execution
  1078.      until it exits the loop.  In contrast, a `next' command at the end
  1079.      of a loop simply steps back to the beginning of the loop, which
  1080.      forces you to step through the next iteration.
  1081.  
  1082.      `until' always stops your program if it attempts to exit the
  1083.      current stack frame.
  1084.  
  1085.      `until' may produce somewhat counterintuitive results if the order
  1086.      of machine code does not match the order of the source lines.  For
  1087.      example, in the following excerpt from a debugging session, the `f'
  1088.      (`frame') command shows that execution is stopped at line `206';
  1089.      yet when we use `until', we get to line `195':
  1090.  
  1091.           (gdb) f
  1092.           #0  main (argc=4, argv=0xf7fffae8) at m4.c:206
  1093.           206                 expand_input();
  1094.           (gdb) until
  1095.           195             for ( ; argc > 0; NEXTARG) {
  1096.  
  1097.      This happened because, for execution efficiency, the compiler had
  1098.      generated code for the loop closure test at the end, rather than
  1099.      the start, of the loop--even though the test in a C `for'-loop is
  1100.      written before the body of the loop.  The `until' command appeared
  1101.      to step back to the beginning of the loop when it advanced to this
  1102.      expression; however, it has not really gone to an earlier
  1103.      statement--not in terms of the actual machine code.
  1104.  
  1105.      `until' with no argument works by means of single instruction
  1106.      stepping, and hence is slower than `until' with an argument.
  1107.  
  1108. `until LOCATION'
  1109. `u LOCATION'
  1110.      Continue running your program until either the specified location
  1111.      is reached, or the current stack frame returns.  LOCATION is any of
  1112.      the forms of argument acceptable to `break' (*note Setting
  1113.      breakpoints: Set Breaks.).  This form of the command uses
  1114.      breakpoints, and hence is quicker than `until' without an argument.
  1115.  
  1116. `stepi'
  1117. `si'
  1118.      Execute one machine instruction, then stop and return to the
  1119.      debugger.
  1120.  
  1121.      It is often useful to do `display/i $pc' when stepping by machine
  1122.      instructions.  This makes GDB automatically display the next
  1123.      instruction to be executed, each time your program stops.  *Note
  1124.      Automatic display: Auto Display.
  1125.  
  1126.      An argument is a repeat count, as in `step'.
  1127.  
  1128. `nexti'
  1129. `ni'
  1130.      Execute one machine instruction, but if it is a function call,
  1131.      proceed until the function returns.
  1132.  
  1133.      An argument is a repeat count, as in `next'.
  1134.  
  1135. 
  1136. File: gdb.info,  Node: Signals,  Next: Thread Stops,  Prev: Continuing and Stepping,  Up: Stopping
  1137.  
  1138. Signals
  1139. =======
  1140.  
  1141.    A signal is an asynchronous event that can happen in a program.  The
  1142. operating system defines the possible kinds of signals, and gives each
  1143. kind a name and a number.  For example, in Unix `SIGINT' is the signal
  1144. a program gets when you type an interrupt (often `C-c'); `SIGSEGV' is
  1145. the signal a program gets from referencing a place in memory far away
  1146. from all the areas in use; `SIGALRM' occurs when the alarm clock timer
  1147. goes off (which happens only if your program has requested an alarm).
  1148.  
  1149.    Some signals, including `SIGALRM', are a normal part of the
  1150. functioning of your program.  Others, such as `SIGSEGV', indicate
  1151. errors; these signals are "fatal" (kill your program immediately) if the
  1152. program has not specified in advance some other way to handle the
  1153. signal.  `SIGINT' does not indicate an error in your program, but it is
  1154. normally fatal so it can carry out the purpose of the interrupt: to
  1155. kill the program.
  1156.  
  1157.    GDB has the ability to detect any occurrence of a signal in your
  1158. program.  You can tell GDB in advance what to do for each kind of
  1159. signal.
  1160.  
  1161.    Normally, GDB is set up to ignore non-erroneous signals like
  1162. `SIGALRM' (so as not to interfere with their role in the functioning of
  1163. your program) but to stop your program immediately whenever an error
  1164. signal happens.  You can change these settings with the `handle'
  1165. command.
  1166.  
  1167. `info signals'
  1168.      Print a table of all the kinds of signals and how GDB has been
  1169.      told to handle each one.  You can use this to see the signal
  1170.      numbers of all the defined types of signals.
  1171.  
  1172. `handle SIGNAL KEYWORDS...'
  1173.      Change the way GDB handles signal SIGNAL.  SIGNAL can be the
  1174.      number of a signal or its name (with or without the `SIG' at the
  1175.      beginning).  The KEYWORDS say what change to make.
  1176.  
  1177.    The keywords allowed by the `handle' command can be abbreviated.
  1178. Their full names are:
  1179.  
  1180. `nostop'
  1181.      GDB should not stop your program when this signal happens.  It may
  1182.      still print a message telling you that the signal has come in.
  1183.  
  1184. `stop'
  1185.      GDB should stop your program when this signal happens.  This
  1186.      implies the `print' keyword as well.
  1187.  
  1188. `print'
  1189.      GDB should print a message when this signal happens.
  1190.  
  1191. `noprint'
  1192.      GDB should not mention the occurrence of the signal at all.  This
  1193.      implies the `nostop' keyword as well.
  1194.  
  1195. `pass'
  1196.      GDB should allow your program to see this signal; your program can
  1197.      handle the signal, or else it may terminate if the signal is fatal
  1198.      and not handled.
  1199.  
  1200. `nopass'
  1201.      GDB should not allow your program to see this signal.
  1202.  
  1203.    When a signal stops your program, the signal is not visible until you
  1204. continue.  Your program sees the signal then, if `pass' is in effect
  1205. for the signal in question *at that time*.  In other words, after GDB
  1206. reports a signal, you can use the `handle' command with `pass' or
  1207. `nopass' to control whether your program sees that signal when you
  1208. continue.
  1209.  
  1210.    You can also use the `signal' command to prevent your program from
  1211. seeing a signal, or cause it to see a signal it normally would not see,
  1212. or to give it any signal at any time.  For example, if your program
  1213. stopped due to some sort of memory reference error, you might store
  1214. correct values into the erroneous variables and continue, hoping to see
  1215. more execution; but your program would probably terminate immediately as
  1216. a result of the fatal signal once it saw the signal.  To prevent this,
  1217. you can continue with `signal 0'.  *Note Giving your program a signal:
  1218. Signaling.
  1219.  
  1220.