OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [insight/] [gdb/] [doc/] [gdb.info-1] - Blame information for rev 1765

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 578 markom
This is ./gdb.info, produced by makeinfo version 4.0 from gdb.texinfo.
2
 
3
INFO-DIR-SECTION Programming & development tools.
4
START-INFO-DIR-ENTRY
5
* Gdb: (gdb).                     The GNU debugger.
6
END-INFO-DIR-ENTRY
7
 
8
   This file documents the GNU debugger GDB.
9
 
10
   This is the Ninth Edition, April 2001, of `Debugging with GDB: the
11
GNU Source-Level Debugger' for GDB Version 20010707.
12
 
13
   Copyright (C)
14
1988,1989,1990,1991,1992,1993,1994,1995,1996,1998,1999,2000,2001
15
Free Software Foundation, Inc.
16
 
17
   Permission is granted to copy, distribute and/or modify this document
18
under the terms of the GNU Free Documentation License, Version 1.1 or
19
any later version published by the Free Software Foundation; with the
20
Invariant Sections being "A Sample GDB Session" and "Free Software",
21
with the Front-Cover texts being "A GNU Manual," and with the
22
Back-Cover Texts as in (a) below.
23
 
24
   (a) The FSF's Back-Cover Text is: "You have freedom to copy and
25
modify this GNU Manual, like GNU software.  Copies published by the Free
26
Software Foundation raise funds for GNU development."
27
 
28

29
File: gdb.info,  Node: Top,  Next: Summary,  Prev: (dir),  Up: (dir)
30
 
31
Debugging with GDB
32
******************
33
 
34
   This file describes GDB, the GNU symbolic debugger.
35
 
36
   This is the Ninth Edition, April 2001, for GDB Version 20010707.
37
 
38
   Copyright (C) 1988-2001 Free Software Foundation, Inc.
39
 
40
* Menu:
41
 
42
* Summary::                     Summary of GDB
43
* Sample Session::              A sample GDB session
44
 
45
* Invocation::                  Getting in and out of GDB
46
* Commands::                    GDB commands
47
* Running::                     Running programs under GDB
48
* Stopping::                    Stopping and continuing
49
* Stack::                       Examining the stack
50
* Source::                      Examining source files
51
* Data::                        Examining data
52
* Tracepoints::                 Debugging remote targets non-intrusively
53
 
54
* Languages::                   Using GDB with different languages
55
 
56
* Symbols::                     Examining the symbol table
57
* Altering::                    Altering execution
58
* GDB Files::                   GDB files
59
* Targets::                     Specifying a debugging target
60
* Configurations::              Configuration-specific information
61
* Controlling GDB::             Controlling GDB
62
* Sequences::                   Canned sequences of commands
63
* Emacs::                       Using GDB under GNU Emacs
64
* Annotations::                 GDB's annotation interface.
65
* GDB/MI::                      GDB's Machine Interface.
66
 
67
* GDB Bugs::                    Reporting bugs in GDB
68
* Formatting Documentation::    How to format and print GDB documentation
69
 
70
* Command Line Editing::        Command Line Editing
71
* Using History Interactively:: Using History Interactively
72
* Installing GDB::              Installing GDB
73
* Index::                       Index
74
 
75

76
File: gdb.info,  Node: Summary,  Next: Sample Session,  Prev: Top,  Up: Top
77
 
78
Summary of GDB
79
**************
80
 
81
   The purpose of a debugger such as GDB is to allow you to see what is
82
going on "inside" another program while it executes--or what another
83
program was doing at the moment it crashed.
84
 
85
   GDB can do four main kinds of things (plus other things in support of
86
these) to help you catch bugs in the act:
87
 
88
   * Start your program, specifying anything that might affect its
89
     behavior.
90
 
91
   * Make your program stop on specified conditions.
92
 
93
   * Examine what has happened, when your program has stopped.
94
 
95
   * Change things in your program, so you can experiment with
96
     correcting the effects of one bug and go on to learn about another.
97
 
98
   You can use GDB to debug programs written in C and C++.  For more
99
information, see *Note Supported languages: Support.  For more
100
information, see *Note C and C++: C.
101
 
102
   Support for Modula-2 and Chill is partial.  For information on
103
Modula-2, see *Note Modula-2: Modula-2.  For information on Chill, see
104
*Note Chill::.
105
 
106
   Debugging Pascal programs which use sets, subranges, file variables,
107
or nested functions does not currently work.  GDB does not support
108
entering expressions, printing values, or similar features using Pascal
109
syntax.
110
 
111
   GDB can be used to debug programs written in Fortran, although it
112
may be necessary to refer to some variables with a trailing underscore.
113
 
114
* Menu:
115
 
116
* Free Software::               Freely redistributable software
117
* Contributors::                Contributors to GDB
118
 
119

120
File: gdb.info,  Node: Free Software,  Next: Contributors,  Up: Summary
121
 
122
Free software
123
=============
124
 
125
   GDB is "free software", protected by the GNU General Public License
126
(GPL).  The GPL gives you the freedom to copy or adapt a licensed
127
program--but every person getting a copy also gets with it the freedom
128
to modify that copy (which means that they must get access to the
129
source code), and the freedom to distribute further copies.  Typical
130
software companies use copyrights to limit your freedoms; the Free
131
Software Foundation uses the GPL to preserve these freedoms.
132
 
133
   Fundamentally, the General Public License is a license which says
134
that you have these freedoms and that you cannot take these freedoms
135
away from anyone else.
136
 
137

138
File: gdb.info,  Node: Contributors,  Prev: Free Software,  Up: Summary
139
 
140
Contributors to GDB
141
===================
142
 
143
   Richard Stallman was the original author of GDB, and of many other
144
GNU programs.  Many others have contributed to its development.  This
145
section attempts to credit major contributors.  One of the virtues of
146
free software is that everyone is free to contribute to it; with
147
regret, we cannot actually acknowledge everyone here.  The file
148
`ChangeLog' in the GDB distribution approximates a blow-by-blow account.
149
 
150
   Changes much prior to version 2.0 are lost in the mists of time.
151
 
152
     _Plea:_ Additions to this section are particularly welcome.  If you
153
     or your friends (or enemies, to be evenhanded) have been unfairly
154
     omitted from this list, we would like to add your names!
155
 
156
   So that they may not regard their many labors as thankless, we
157
particularly thank those who shepherded GDB through major releases:
158
Andrew Cagney (releases 5.0 and 5.1); Jim Blandy (release 4.18); Jason
159
Molenda (release 4.17); Stan Shebs (release 4.14); Fred Fish (releases
160
4.16, 4.15, 4.13, 4.12, 4.11, 4.10, and 4.9); Stu Grossman and John
161
Gilmore (releases 4.8, 4.7, 4.6, 4.5, and 4.4); John Gilmore (releases
162
4.3, 4.2, 4.1, 4.0, and 3.9); Jim Kingdon (releases 3.5, 3.4, and 3.3);
163
and Randy Smith (releases 3.2, 3.1, and 3.0).
164
 
165
   Richard Stallman, assisted at various times by Peter TerMaat, Chris
166
Hanson, and Richard Mlynarik, handled releases through 2.8.
167
 
168
   Michael Tiemann is the author of most of the GNU C++ support in GDB,
169
with significant additional contributions from Per Bothner and Daniel
170
Berlin.  James Clark wrote the GNU C++ demangler.  Early work on C++
171
was by Peter TerMaat (who also did much general update work leading to
172
release 3.0).
173
 
174
   GDB uses the BFD subroutine library to examine multiple object-file
175
formats; BFD was a joint project of David V.  Henkel-Wallace, Rich
176
Pixley, Steve Chamberlain, and John Gilmore.
177
 
178
   David Johnson wrote the original COFF support; Pace Willison did the
179
original support for encapsulated COFF.
180
 
181
   Brent Benson of Harris Computer Systems contributed DWARF2 support.
182
 
183
   Adam de Boor and Bradley Davis contributed the ISI Optimum V support.
184
Per Bothner, Noboyuki Hikichi, and Alessandro Forin contributed MIPS
185
support.  Jean-Daniel Fekete contributed Sun 386i support.  Chris
186
Hanson improved the HP9000 support.  Noboyuki Hikichi and Tomoyuki
187
Hasei contributed Sony/News OS 3 support.  David Johnson contributed
188
Encore Umax support.  Jyrki Kuoppala contributed Altos 3068 support.
189
Jeff Law contributed HP PA and SOM support.  Keith Packard contributed
190
NS32K support.  Doug Rabson contributed Acorn Risc Machine support.
191
Bob Rusk contributed Harris Nighthawk CX-UX support.  Chris Smith
192
contributed Convex support (and Fortran debugging).  Jonathan Stone
193
contributed Pyramid support.  Michael Tiemann contributed SPARC support.
194
Tim Tucker contributed support for the Gould NP1 and Gould Powernode.
195
Pace Willison contributed Intel 386 support.  Jay Vosburgh contributed
196
Symmetry support.
197
 
198
   Andreas Schwab contributed M68K Linux support.
199
 
200
   Rich Schaefer and Peter Schauer helped with support of SunOS shared
201
libraries.
202
 
203
   Jay Fenlason and Roland McGrath ensured that GDB and GAS agree about
204
several machine instruction sets.
205
 
206
   Patrick Duval, Ted Goldstein, Vikram Koka and Glenn Engel helped
207
develop remote debugging.  Intel Corporation, Wind River Systems, AMD,
208
and ARM contributed remote debugging modules for the i960, VxWorks,
209
A29K UDI, and RDI targets, respectively.
210
 
211
   Brian Fox is the author of the readline libraries providing
212
command-line editing and command history.
213
 
214
   Andrew Beers of SUNY Buffalo wrote the language-switching code, the
215
Modula-2 support, and contributed the Languages chapter of this manual.
216
 
217
   Fred Fish wrote most of the support for Unix System Vr4.  He also
218
enhanced the command-completion support to cover C++ overloaded symbols.
219
 
220
   Hitachi America, Ltd. sponsored the support for H8/300, H8/500, and
221
Super-H processors.
222
 
223
   NEC sponsored the support for the v850, Vr4xxx, and Vr5xxx
224
processors.
225
 
226
   Mitsubishi sponsored the support for D10V, D30V, and M32R/D
227
processors.
228
 
229
   Toshiba sponsored the support for the TX39 Mips processor.
230
 
231
   Matsushita sponsored the support for the MN10200 and MN10300
232
processors.
233
 
234
   Fujitsu sponsored the support for SPARClite and FR30 processors.
235
 
236
   Kung Hsu, Jeff Law, and Rick Sladkey added support for hardware
237
watchpoints.
238
 
239
   Michael Snyder added support for tracepoints.
240
 
241
   Stu Grossman wrote gdbserver.
242
 
243
   Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made nearly
244
innumerable bug fixes and cleanups throughout GDB.
245
 
246
   The following people at the Hewlett-Packard Company contributed
247
support for the PA-RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0
248
(narrow mode), HP's implementation of kernel threads, HP's aC++
249
compiler, and the terminal user interface: Ben Krepp, Richard Title,
250
John Bishop, Susan Macchia, Kathy Mann, Satish Pai, India Paul, Steve
251
Rehrauer, and Elena Zannoni.  Kim Haase provided HP-specific
252
information in this manual.
253
 
254
   DJ Delorie ported GDB to MS-DOS, for the DJGPP project.  Robert
255
Hoehne made significant contributions to the DJGPP port.
256
 
257
   Cygnus Solutions has sponsored GDB maintenance and much of its
258
development since 1991.  Cygnus engineers who have worked on GDB
259
fulltime include Mark Alexander, Jim Blandy, Per Bothner, Kevin
260
Buettner, Edith Epstein, Chris Faylor, Fred Fish, Martin Hunt, Jim
261
Ingham, John Gilmore, Stu Grossman, Kung Hsu, Jim Kingdon, John Metzler,
262
Fernando Nasser, Geoffrey Noer, Dawn Perchik, Rich Pixley, Zdenek
263
Radouch, Keith Seitz, Stan Shebs, David Taylor, and Elena Zannoni.  In
264
addition, Dave Brolley, Ian Carmichael, Steve Chamberlain, Nick Clifton,
265
JT Conklin, Stan Cox, DJ Delorie, Ulrich Drepper, Frank Eigler, Doug
266
Evans, Sean Fagan, David Henkel-Wallace, Richard Henderson, Jeff
267
Holcomb, Jeff Law, Jim Lemke, Tom Lord, Bob Manson, Michael Meissner,
268
Jason Merrill, Catherine Moore, Drew Moseley, Ken Raeburn, Gavin
269
Romig-Koch, Rob Savoye, Jamie Smith, Mike Stump, Ian Taylor, Angela
270
Thomas, Michael Tiemann, Tom Tromey, Ron Unrau, Jim Wilson, and David
271
Zuhn have made contributions both large and small.
272
 
273

274
File: gdb.info,  Node: Sample Session,  Next: Invocation,  Prev: Summary,  Up: Top
275
 
276
A Sample GDB Session
277
********************
278
 
279
   You can use this manual at your leisure to read all about GDB.
280
However, a handful of commands are enough to get started using the
281
debugger.  This chapter illustrates those commands.
282
 
283
   One of the preliminary versions of GNU `m4' (a generic macro
284
processor) exhibits the following bug: sometimes, when we change its
285
quote strings from the default, the commands used to capture one macro
286
definition within another stop working.  In the following short `m4'
287
session, we define a macro `foo' which expands to `0000'; we then use
288
the `m4' built-in `defn' to define `bar' as the same thing.  However,
289
when we change the open quote string to `' and the close quote
290
string to `', the same procedure fails to define a new synonym
291
`baz':
292
 
293
     $ cd gnu/m4
294
     $ ./m4
295
     define(foo,0000)
296
 
297
     foo
298
     0000
299
     define(bar,defn(`foo'))
300
 
301
     bar
302
     0000
303
     changequote(,)
304
 
305
     define(baz,defn(foo))
306
     baz
307
     C-d
308
     m4: End of input: 0: fatal error: EOF in string
309
 
310
Let us use GDB to try to see what is going on.
311
 
312
     $ gdb m4
313
     GDB is free software and you are welcome to distribute copies
314
      of it under certain conditions; type "show copying" to see
315
      the conditions.
316
     There is absolutely no warranty for GDB; type "show warranty"
317
      for details.
318
 
319
     GDB 20010707, Copyright 1999 Free Software Foundation, Inc...
320
     (gdb)
321
 
322
GDB reads only enough symbol data to know where to find the rest when
323
needed; as a result, the first prompt comes up very quickly.  We now
324
tell GDB to use a narrower display width than usual, so that examples
325
fit in this manual.
326
 
327
     (gdb) set width 70
328
 
329
We need to see how the `m4' built-in `changequote' works.  Having
330
looked at the source, we know the relevant subroutine is
331
`m4_changequote', so we set a breakpoint there with the GDB `break'
332
command.
333
 
334
     (gdb) break m4_changequote
335
     Breakpoint 1 at 0x62f4: file builtin.c, line 879.
336
 
337
Using the `run' command, we start `m4' running under GDB control; as
338
long as control does not reach the `m4_changequote' subroutine, the
339
program runs as usual:
340
 
341
     (gdb) run
342
     Starting program: /work/Editorial/gdb/gnu/m4/m4
343
     define(foo,0000)
344
 
345
     foo
346
     0000
347
 
348
To trigger the breakpoint, we call `changequote'.  GDB suspends
349
execution of `m4', displaying information about the context where it
350
stops.
351
 
352
     changequote(,)
353
 
354
     Breakpoint 1, m4_changequote (argc=3, argv=0x33c70)
355
         at builtin.c:879
356
     879         if (bad_argc(TOKEN_DATA_TEXT(argv[0]),argc,1,3))
357
 
358
Now we use the command `n' (`next') to advance execution to the next
359
line of the current function.
360
 
361
     (gdb) n
362
     882         set_quotes((argc >= 2) ? TOKEN_DATA_TEXT(argv[1])\
363
      : nil,
364
 
365
`set_quotes' looks like a promising subroutine.  We can go into it by
366
using the command `s' (`step') instead of `next'.  `step' goes to the
367
next line to be executed in _any_ subroutine, so it steps into
368
`set_quotes'.
369
 
370
     (gdb) s
371
     set_quotes (lq=0x34c78 "", rq=0x34c88 "")
372
         at input.c:530
373
     530         if (lquote != def_lquote)
374
 
375
The display that shows the subroutine where `m4' is now suspended (and
376
its arguments) is called a stack frame display.  It shows a summary of
377
the stack.  We can use the `backtrace' command (which can also be
378
spelled `bt'), to see where we are in the stack as a whole: the
379
`backtrace' command displays a stack frame for each active subroutine.
380
 
381
     (gdb) bt
382
     #0  set_quotes (lq=0x34c78 "", rq=0x34c88 "")
383
         at input.c:530
384
     #1  0x6344 in m4_changequote (argc=3, argv=0x33c70)
385
         at builtin.c:882
386
     #2  0x8174 in expand_macro (sym=0x33320) at macro.c:242
387
     #3  0x7a88 in expand_token (obs=0x0, t=209696, td=0xf7fffa30)
388
         at macro.c:71
389
     #4  0x79dc in expand_input () at macro.c:40
390
     #5  0x2930 in main (argc=0, argv=0xf7fffb20) at m4.c:195
391
 
392
We step through a few more lines to see what happens.  The first two
393
times, we can use `s'; the next two times we use `n' to avoid falling
394
into the `xstrdup' subroutine.
395
 
396
     (gdb) s
397
     0x3b5c  532         if (rquote != def_rquote)
398
     (gdb) s
399
     0x3b80  535         lquote = (lq == nil || *lq == '\0') ?  \
400
     def_lquote : xstrdup(lq);
401
     (gdb) n
402
     536         rquote = (rq == nil || *rq == '\0') ? def_rquote\
403
      : xstrdup(rq);
404
     (gdb) n
405
     538         len_lquote = strlen(rquote);
406
 
407
The last line displayed looks a little odd; we can examine the variables
408
`lquote' and `rquote' to see if they are in fact the new left and right
409
quotes we specified.  We use the command `p' (`print') to see their
410
values.
411
 
412
     (gdb) p lquote
413
     $1 = 0x35d40 ""
414
     (gdb) p rquote
415
     $2 = 0x35d50 ""
416
 
417
`lquote' and `rquote' are indeed the new left and right quotes.  To
418
look at some context, we can display ten lines of source surrounding
419
the current line with the `l' (`list') command.
420
 
421
     (gdb) l
422
     533             xfree(rquote);
423
     534
424
     535         lquote = (lq == nil || *lq == '\0') ? def_lquote\
425
      : xstrdup (lq);
426
     536         rquote = (rq == nil || *rq == '\0') ? def_rquote\
427
      : xstrdup (rq);
428
     537
429
     538         len_lquote = strlen(rquote);
430
     539         len_rquote = strlen(lquote);
431
     540     }
432
     541
433
     542     void
434
 
435
Let us step past the two lines that set `len_lquote' and `len_rquote',
436
and then examine the values of those variables.
437
 
438
     (gdb) n
439
     539         len_rquote = strlen(lquote);
440
     (gdb) n
441
     540     }
442
     (gdb) p len_lquote
443
     $3 = 9
444
     (gdb) p len_rquote
445
     $4 = 7
446
 
447
That certainly looks wrong, assuming `len_lquote' and `len_rquote' are
448
meant to be the lengths of `lquote' and `rquote' respectively.  We can
449
set them to better values using the `p' command, since it can print the
450
value of any expression--and that expression can include subroutine
451
calls and assignments.
452
 
453
     (gdb) p len_lquote=strlen(lquote)
454
     $5 = 7
455
     (gdb) p len_rquote=strlen(rquote)
456
     $6 = 9
457
 
458
Is that enough to fix the problem of using the new quotes with the `m4'
459
built-in `defn'?  We can allow `m4' to continue executing with the `c'
460
(`continue') command, and then try the example that caused trouble
461
initially:
462
 
463
     (gdb) c
464
     Continuing.
465
 
466
     define(baz,defn(foo))
467
 
468
     baz
469
     0000
470
 
471
Success!  The new quotes now work just as well as the default ones.  The
472
problem seems to have been just the two typos defining the wrong
473
lengths.  We allow `m4' exit by giving it an EOF as input:
474
 
475
     C-d
476
     Program exited normally.
477
 
478
The message `Program exited normally.' is from GDB; it indicates `m4'
479
has finished executing.  We can end our GDB session with the GDB `quit'
480
command.
481
 
482
     (gdb) quit
483
 
484

485
File: gdb.info,  Node: Invocation,  Next: Commands,  Prev: Sample Session,  Up: Top
486
 
487
Getting In and Out of GDB
488
*************************
489
 
490
   This chapter discusses how to start GDB, and how to get out of it.
491
The essentials are:
492
   * type `gdb' to start GDB.
493
 
494
   * type `quit' or `C-d' to exit.
495
 
496
* Menu:
497
 
498
* Invoking GDB::                How to start GDB
499
* Quitting GDB::                How to quit GDB
500
* Shell Commands::              How to use shell commands inside GDB
501
 
502

503
File: gdb.info,  Node: Invoking GDB,  Next: Quitting GDB,  Up: Invocation
504
 
505
Invoking GDB
506
============
507
 
508
   Invoke GDB by running the program `gdb'.  Once started, GDB reads
509
commands from the terminal until you tell it to exit.
510
 
511
   You can also run `gdb' with a variety of arguments and options, to
512
specify more of your debugging environment at the outset.
513
 
514
   The command-line options described here are designed to cover a
515
variety of situations; in some environments, some of these options may
516
effectively be unavailable.
517
 
518
   The most usual way to start GDB is with one argument, specifying an
519
executable program:
520
 
521
     gdb PROGRAM
522
 
523
You can also start with both an executable program and a core file
524
specified:
525
 
526
     gdb PROGRAM CORE
527
 
528
   You can, instead, specify a process ID as a second argument, if you
529
want to debug a running process:
530
 
531
     gdb PROGRAM 1234
532
 
533
would attach GDB to process `1234' (unless you also have a file named
534
`1234'; GDB does check for a core file first).
535
 
536
   Taking advantage of the second command-line argument requires a
537
fairly complete operating system; when you use GDB as a remote debugger
538
attached to a bare board, there may not be any notion of "process", and
539
there is often no way to get a core dump.  GDB will warn you if it is
540
unable to attach or to read core dumps.
541
 
542
   You can run `gdb' without printing the front material, which
543
describes GDB's non-warranty, by specifying `-silent':
544
 
545
     gdb -silent
546
 
547
You can further control how GDB starts up by using command-line
548
options.  GDB itself can remind you of the options available.
549
 
550
Type
551
 
552
     gdb -help
553
 
554
to display all available options and briefly describe their use (`gdb
555
-h' is a shorter equivalent).
556
 
557
   All options and command line arguments you give are processed in
558
sequential order.  The order makes a difference when the `-x' option is
559
used.
560
 
561
* Menu:
562
 
563
* File Options::                Choosing files
564
* Mode Options::                Choosing modes
565
 
566

567
File: gdb.info,  Node: File Options,  Next: Mode Options,  Up: Invoking GDB
568
 
569
Choosing files
570
--------------
571
 
572
   When GDB starts, it reads any arguments other than options as
573
specifying an executable file and core file (or process ID).  This is
574
the same as if the arguments were specified by the `-se' and `-c'
575
options respectively.  (GDB reads the first argument that does not have
576
an associated option flag as equivalent to the `-se' option followed by
577
that argument; and the second argument that does not have an associated
578
option flag, if any, as equivalent to the `-c' option followed by that
579
argument.)
580
 
581
   If GDB has not been configured to included core file support, such
582
as for most embedded targets, then it will complain about a second
583
argument and ignore it.
584
 
585
   Many options have both long and short forms; both are shown in the
586
following list.  GDB also recognizes the long forms if you truncate
587
them, so long as enough of the option is present to be unambiguous.
588
(If you prefer, you can flag option arguments with `--' rather than
589
`-', though we illustrate the more usual convention.)
590
 
591
`-symbols FILE'
592
`-s FILE'
593
     Read symbol table from file FILE.
594
 
595
`-exec FILE'
596
`-e FILE'
597
     Use file FILE as the executable file to execute when appropriate,
598
     and for examining pure data in conjunction with a core dump.
599
 
600
`-se FILE'
601
     Read symbol table from file FILE and use it as the executable file.
602
 
603
`-core FILE'
604
`-c FILE'
605
     Use file FILE as a core dump to examine.
606
 
607
`-c NUMBER'
608
     Connect to process ID NUMBER, as with the `attach' command (unless
609
     there is a file in core-dump format named NUMBER, in which case
610
     `-c' specifies that file as a core dump to read).
611
 
612
`-command FILE'
613
`-x FILE'
614
     Execute GDB commands from file FILE.  *Note Command files: Command
615
     Files.
616
 
617
`-directory DIRECTORY'
618
`-d DIRECTORY'
619
     Add DIRECTORY to the path to search for source files.
620
 
621
`-m'
622
`-mapped'
623
     _Warning: this option depends on operating system facilities that
624
     are not supported on all systems._
625
     If memory-mapped files are available on your system through the
626
     `mmap' system call, you can use this option to have GDB write the
627
     symbols from your program into a reusable file in the current
628
     directory.  If the program you are debugging is called
629
     `/tmp/fred', the mapped symbol file is `/tmp/fred.syms'.  Future
630
     GDB debugging sessions notice the presence of this file, and can
631
     quickly map in symbol information from it, rather than reading the
632
     symbol table from the executable program.
633
 
634
     The `.syms' file is specific to the host machine where GDB is run.
635
     It holds an exact image of the internal GDB symbol table.  It
636
     cannot be shared across multiple host platforms.
637
 
638
`-r'
639
`-readnow'
640
     Read each symbol file's entire symbol table immediately, rather
641
     than the default, which is to read it incrementally as it is
642
     needed.  This makes startup slower, but makes future operations
643
     faster.
644
 
645
   You typically combine the `-mapped' and `-readnow' options in order
646
to build a `.syms' file that contains complete symbol information.
647
(*Note Commands to specify files: Files, for information on `.syms'
648
files.)  A simple GDB invocation to do nothing but build a `.syms' file
649
for future use is:
650
 
651
     gdb -batch -nx -mapped -readnow programname
652
 
653

654
File: gdb.info,  Node: Mode Options,  Prev: File Options,  Up: Invoking GDB
655
 
656
Choosing modes
657
--------------
658
 
659
   You can run GDB in various alternative modes--for example, in batch
660
mode or quiet mode.
661
 
662
`-nx'
663
`-n'
664
     Do not execute commands found in any initialization files (normally
665
     called `.gdbinit', or `gdb.ini' on PCs).  Normally, GDB executes
666
     the commands in these files after all the command options and
667
     arguments have been processed.  *Note Command files: Command Files.
668
 
669
`-quiet'
670
`-silent'
671
`-q'
672
     "Quiet".  Do not print the introductory and copyright messages.
673
     These messages are also suppressed in batch mode.
674
 
675
`-batch'
676
     Run in batch mode.  Exit with status `0' after processing all the
677
     command files specified with `-x' (and all commands from
678
     initialization files, if not inhibited with `-n').  Exit with
679
     nonzero status if an error occurs in executing the GDB commands in
680
     the command files.
681
 
682
     Batch mode may be useful for running GDB as a filter, for example
683
     to download and run a program on another computer; in order to
684
     make this more useful, the message
685
 
686
          Program exited normally.
687
 
688
     (which is ordinarily issued whenever a program running under GDB
689
     control terminates) is not issued when running in batch mode.
690
 
691
`-nowindows'
692
`-nw'
693
     "No windows".  If GDB comes with a graphical user interface (GUI)
694
     built in, then this option tells GDB to only use the command-line
695
     interface.  If no GUI is available, this option has no effect.
696
 
697
`-windows'
698
`-w'
699
     If GDB includes a GUI, then this option requires it to be used if
700
     possible.
701
 
702
`-cd DIRECTORY'
703
     Run GDB using DIRECTORY as its working directory, instead of the
704
     current directory.
705
 
706
`-fullname'
707
`-f'
708
     GNU Emacs sets this option when it runs GDB as a subprocess.  It
709
     tells GDB to output the full file name and line number in a
710
     standard, recognizable fashion each time a stack frame is
711
     displayed (which includes each time your program stops).  This
712
     recognizable format looks like two `\032' characters, followed by
713
     the file name, line number and character position separated by
714
     colons, and a newline.  The Emacs-to-GDB interface program uses
715
     the two `\032' characters as a signal to display the source code
716
     for the frame.
717
 
718
`-epoch'
719
     The Epoch Emacs-GDB interface sets this option when it runs GDB as
720
     a subprocess.  It tells GDB to modify its print routines so as to
721
     allow Epoch to display values of expressions in a separate window.
722
 
723
`-annotate LEVEL'
724
     This option sets the "annotation level" inside GDB.  Its effect is
725
     identical to using `set annotate LEVEL' (*note Annotations::).
726
     Annotation level controls how much information does GDB print
727
     together with its prompt, values of expressions, source lines, and
728
     other types of output.  Level 0 is the normal, level 1 is for use
729
     when GDB is run as a subprocess of GNU Emacs, level 2 is the
730
     maximum annotation suitable for programs that control GDB.
731
 
732
`-async'
733
     Use the asynchronous event loop for the command-line interface.
734
     GDB processes all events, such as user keyboard input, via a
735
     special event loop.  This allows GDB to accept and process user
736
     commands in parallel with the debugged process being run(1), so
737
     you don't need to wait for control to return to GDB before you
738
     type the next command.  (_Note:_ as of version 5.1, the target
739
     side of the asynchronous operation is not yet in place, so
740
     `-async' does not work fully yet.)
741
 
742
     When the standard input is connected to a terminal device, GDB
743
     uses the asynchronous event loop by default, unless disabled by the
744
     `-noasync' option.
745
 
746
`-noasync'
747
     Disable the asynchronous event loop for the command-line interface.
748
 
749
`-baud BPS'
750
`-b BPS'
751
     Set the line speed (baud rate or bits per second) of any serial
752
     interface used by GDB for remote debugging.
753
 
754
`-tty DEVICE'
755
`-t DEVICE'
756
     Run using DEVICE for your program's standard input and output.
757
 
758
`-interpreter INTERP'
759
     Use the interpreter INTERP for interface with the controlling
760
     program or device.  This option is meant to be set by programs
761
     which communicate with GDB using it as a back end.
762
 
763
     `--interpreter=mi' (or `--interpreter=mi1') causes GDB to use the
764
     "gdb/mi interface" (*note The GDB/MI Interface: GDB/MI.). The
765
     older GDB/MI interface, included in GDB version 5.0 can be
766
     selected with `--interpreter=mi0'.
767
 
768
`-write'
769
     Open the executable and core files for both reading and writing.
770
     This is equivalent to the `set write on' command inside GDB (*note
771
     Patching::).
772
 
773
`-statistics'
774
     This option causes GDB to print statistics about time and memory
775
     usage after it completes each command and returns to the prompt.
776
 
777
`-version'
778
     This option causes GDB to print its version number and no-warranty
779
     blurb, and exit.
780
 
781
   ---------- Footnotes ----------
782
 
783
   (1) GDB built with DJGPP tools for MS-DOS/MS-Windows supports this
784
mode of operation, but the event loop is suspended when the debuggee
785
runs.
786
 
787

788
File: gdb.info,  Node: Quitting GDB,  Next: Shell Commands,  Prev: Invoking GDB,  Up: Invocation
789
 
790
Quitting GDB
791
============
792
 
793
`quit [EXPRESSION]'
794
`q'
795
     To exit GDB, use the `quit' command (abbreviated `q'), or type an
796
     end-of-file character (usually `C-d').  If you do not supply
797
     EXPRESSION, GDB will terminate normally; otherwise it will
798
     terminate using the result of EXPRESSION as the error code.
799
 
800
   An interrupt (often `C-c') does not exit from GDB, but rather
801
terminates the action of any GDB command that is in progress and
802
returns to GDB command level.  It is safe to type the interrupt
803
character at any time because GDB does not allow it to take effect
804
until a time when it is safe.
805
 
806
   If you have been using GDB to control an attached process or device,
807
you can release it with the `detach' command (*note Debugging an
808
already-running process: Attach.).
809
 
810

811
File: gdb.info,  Node: Shell Commands,  Prev: Quitting GDB,  Up: Invocation
812
 
813
Shell commands
814
==============
815
 
816
   If you need to execute occasional shell commands during your
817
debugging session, there is no need to leave or suspend GDB; you can
818
just use the `shell' command.
819
 
820
`shell COMMAND STRING'
821
     Invoke a standard shell to execute COMMAND STRING.  If it exists,
822
     the environment variable `SHELL' determines which shell to run.
823
     Otherwise GDB uses the default shell (`/bin/sh' on Unix systems,
824
     `COMMAND.COM' on MS-DOS, etc.).
825
 
826
   The utility `make' is often needed in development environments.  You
827
do not have to use the `shell' command for this purpose in GDB:
828
 
829
`make MAKE-ARGS'
830
     Execute the `make' program with the specified arguments.  This is
831
     equivalent to `shell make MAKE-ARGS'.
832
 
833

834
File: gdb.info,  Node: Commands,  Next: Running,  Prev: Invocation,  Up: Top
835
 
836
GDB Commands
837
************
838
 
839
   You can abbreviate a GDB command to the first few letters of the
840
command name, if that abbreviation is unambiguous; and you can repeat
841
certain GDB commands by typing just .  You can also use the 
842
key to get GDB to fill out the rest of a word in a command (or to show
843
you the alternatives available, if there is more than one possibility).
844
 
845
* Menu:
846
 
847
* Command Syntax::              How to give commands to GDB
848
* Completion::                  Command completion
849
* Help::                        How to ask GDB for help
850
 
851

852
File: gdb.info,  Node: Command Syntax,  Next: Completion,  Up: Commands
853
 
854
Command syntax
855
==============
856
 
857
   A GDB command is a single line of input.  There is no limit on how
858
long it can be.  It starts with a command name, which is followed by
859
arguments whose meaning depends on the command name.  For example, the
860
command `step' accepts an argument which is the number of times to
861
step, as in `step 5'.  You can also use the `step' command with no
862
arguments.  Some commands do not allow any arguments.
863
 
864
   GDB command names may always be truncated if that abbreviation is
865
unambiguous.  Other possible command abbreviations are listed in the
866
documentation for individual commands.  In some cases, even ambiguous
867
abbreviations are allowed; for example, `s' is specially defined as
868
equivalent to `step' even though there are other commands whose names
869
start with `s'.  You can test abbreviations by using them as arguments
870
to the `help' command.
871
 
872
   A blank line as input to GDB (typing just ) means to repeat the
873
previous command.  Certain commands (for example, `run') will not
874
repeat this way; these are commands whose unintentional repetition
875
might cause trouble and which you are unlikely to want to repeat.
876
 
877
   The `list' and `x' commands, when you repeat them with ,
878
construct new arguments rather than repeating exactly as typed.  This
879
permits easy scanning of source or memory.
880
 
881
   GDB can also use  in another way: to partition lengthy output,
882
in a way similar to the common utility `more' (*note Screen size:
883
Screen Size.).  Since it is easy to press one  too many in this
884
situation, GDB disables command repetition after any command that
885
generates this sort of display.
886
 
887
   Any text from a `#' to the end of the line is a comment; it does
888
nothing.  This is useful mainly in command files (*note Command files:
889
Command Files.).
890
 
891

892
File: gdb.info,  Node: Completion,  Next: Help,  Prev: Command Syntax,  Up: Commands
893
 
894
Command completion
895
==================
896
 
897
   GDB can fill in the rest of a word in a command for you, if there is
898
only one possibility; it can also show you what the valid possibilities
899
are for the next word in a command, at any time.  This works for GDB
900
commands, GDB subcommands, and the names of symbols in your program.
901
 
902
   Press the  key whenever you want GDB to fill out the rest of a
903
word.  If there is only one possibility, GDB fills in the word, and
904
waits for you to finish the command (or press  to enter it).  For
905
example, if you type
906
 
907
     (gdb) info bre 
908
 
909
GDB fills in the rest of the word `breakpoints', since that is the only
910
`info' subcommand beginning with `bre':
911
 
912
     (gdb) info breakpoints
913
 
914
You can either press  at this point, to run the `info breakpoints'
915
command, or backspace and enter something else, if `breakpoints' does
916
not look like the command you expected.  (If you were sure you wanted
917
`info breakpoints' in the first place, you might as well just type
918
 immediately after `info bre', to exploit command abbreviations
919
rather than command completion).
920
 
921
   If there is more than one possibility for the next word when you
922
press , GDB sounds a bell.  You can either supply more characters
923
and try again, or just press  a second time; GDB displays all the
924
possible completions for that word.  For example, you might want to set
925
a breakpoint on a subroutine whose name begins with `make_', but when
926
you type `b make_' GDB just sounds the bell.  Typing  again
927
displays all the function names in your program that begin with those
928
characters, for example:
929
 
930
     (gdb) b make_ 
931
GDB sounds bell; press  again, to see:
932
     make_a_section_from_file     make_environ
933
     make_abs_section             make_function_type
934
     make_blockvector             make_pointer_type
935
     make_cleanup                 make_reference_type
936
     make_command                 make_symbol_completion_list
937
     (gdb) b make_
938
 
939
After displaying the available possibilities, GDB copies your partial
940
input (`b make_' in the example) so you can finish the command.
941
 
942
   If you just want to see the list of alternatives in the first place,
943
you can press `M-?' rather than pressing  twice.  `M-?' means
944
` ?'.  You can type this either by holding down a key designated
945
as the  shift on your keyboard (if there is one) while typing
946
`?', or as  followed by `?'.
947
 
948
   Sometimes the string you need, while logically a "word", may contain
949
parentheses or other characters that GDB normally excludes from its
950
notion of a word.  To permit word completion to work in this situation,
951
you may enclose words in `'' (single quote marks) in GDB commands.
952
 
953
   The most likely situation where you might need this is in typing the
954
name of a C++ function.  This is because C++ allows function
955
overloading (multiple definitions of the same function, distinguished
956
by argument type).  For example, when you want to set a breakpoint you
957
may need to distinguish whether you mean the version of `name' that
958
takes an `int' parameter, `name(int)', or the version that takes a
959
`float' parameter, `name(float)'.  To use the word-completion
960
facilities in this situation, type a single quote `'' at the beginning
961
of the function name.  This alerts GDB that it may need to consider
962
more information than usual when you press  or `M-?' to request
963
word completion:
964
 
965
     (gdb) b 'bubble( M-?
966
     bubble(double,double)    bubble(int,int)
967
     (gdb) b 'bubble(
968
 
969
   In some cases, GDB can tell that completing a name requires using
970
quotes.  When this happens, GDB inserts the quote for you (while
971
completing as much as it can) if you do not type the quote in the first
972
place:
973
 
974
     (gdb) b bub 
975
GDB alters your input line to the following, and rings a bell:
976
     (gdb) b 'bubble(
977
 
978
In general, GDB can tell that a quote is needed (and inserts it) if you
979
have not yet started typing the argument list when you ask for
980
completion on an overloaded symbol.
981
 
982
   For more information about overloaded functions, see *Note C++
983
expressions: C plus plus expressions.  You can use the command `set
984
overload-resolution off' to disable overload resolution; see *Note GDB
985
features for C++: Debugging C plus plus.
986
 
987

988
File: gdb.info,  Node: Help,  Prev: Completion,  Up: Commands
989
 
990
Getting help
991
============
992
 
993
   You can always ask GDB itself for information on its commands, using
994
the command `help'.
995
 
996
`help'
997
`h'
998
     You can use `help' (abbreviated `h') with no arguments to display
999
     a short list of named classes of commands:
1000
 
1001
          (gdb) help
1002
          List of classes of commands:
1003
 
1004
          aliases -- Aliases of other commands
1005
          breakpoints -- Making program stop at certain points
1006
          data -- Examining data
1007
          files -- Specifying and examining files
1008
          internals -- Maintenance commands
1009
          obscure -- Obscure features
1010
          running -- Running the program
1011
          stack -- Examining the stack
1012
          status -- Status inquiries
1013
          support -- Support facilities
1014
          tracepoints -- Tracing of program execution without
1015
 
1016
          stopping the program
1017
          user-defined -- User-defined commands
1018
 
1019
          Type "help" followed by a class name for a list of
1020
          commands in that class.
1021
          Type "help" followed by command name for full
1022
          documentation.
1023
          Command name abbreviations are allowed if unambiguous.
1024
          (gdb)
1025
 
1026
`help CLASS'
1027
     Using one of the general help classes as an argument, you can get a
1028
     list of the individual commands in that class.  For example, here
1029
     is the help display for the class `status':
1030
 
1031
          (gdb) help status
1032
          Status inquiries.
1033
 
1034
          List of commands:
1035
 
1036
          info -- Generic command for showing things
1037
           about the program being debugged
1038
          show -- Generic command for showing things
1039
           about the debugger
1040
 
1041
          Type "help" followed by command name for full
1042
          documentation.
1043
          Command name abbreviations are allowed if unambiguous.
1044
          (gdb)
1045
 
1046
`help COMMAND'
1047
     With a command name as `help' argument, GDB displays a short
1048
     paragraph on how to use that command.
1049
 
1050
`apropos ARGS'
1051
     The `apropos ARGS' command searches through all of the GDB
1052
     commands, and their documentation, for the regular expression
1053
     specified in ARGS. It prints out all matches found. For example:
1054
 
1055
          apropos reload
1056
 
1057
     results in:
1058
 
1059
          set symbol-reloading -- Set dynamic symbol table reloading
1060
                                           multiple times in one run
1061
          show symbol-reloading -- Show dynamic symbol table reloading
1062
                                           multiple times in one run
1063
 
1064
`complete ARGS'
1065
     The `complete ARGS' command lists all the possible completions for
1066
     the beginning of a command.  Use ARGS to specify the beginning of
1067
     the command you want completed.  For example:
1068
 
1069
          complete i
1070
 
1071
     results in:
1072
 
1073
          if
1074
          ignore
1075
          info
1076
          inspect
1077
 
1078
     This is intended for use by GNU Emacs.
1079
 
1080
   In addition to `help', you can use the GDB commands `info' and
1081
`show' to inquire about the state of your program, or the state of GDB
1082
itself.  Each command supports many topics of inquiry; this manual
1083
introduces each of them in the appropriate context.  The listings under
1084
`info' and under `show' in the Index point to all the sub-commands.
1085
*Note Index::.
1086
 
1087
`info'
1088
     This command (abbreviated `i') is for describing the state of your
1089
     program.  For example, you can list the arguments given to your
1090
     program with `info args', list the registers currently in use with
1091
     `info registers', or list the breakpoints you have set with `info
1092
     breakpoints'.  You can get a complete list of the `info'
1093
     sub-commands with `help info'.
1094
 
1095
`set'
1096
     You can assign the result of an expression to an environment
1097
     variable with `set'.  For example, you can set the GDB prompt to a
1098
     $-sign with `set prompt $'.
1099
 
1100
`show'
1101
     In contrast to `info', `show' is for describing the state of GDB
1102
     itself.  You can change most of the things you can `show', by
1103
     using the related command `set'; for example, you can control what
1104
     number system is used for displays with `set radix', or simply
1105
     inquire which is currently in use with `show radix'.
1106
 
1107
     To display all the settable parameters and their current values,
1108
     you can use `show' with no arguments; you may also use `info set'.
1109
     Both commands produce the same display.
1110
 
1111
   Here are three miscellaneous `show' subcommands, all of which are
1112
exceptional in lacking corresponding `set' commands:
1113
 
1114
`show version'
1115
     Show what version of GDB is running.  You should include this
1116
     information in GDB bug-reports.  If multiple versions of GDB are
1117
     in use at your site, you may need to determine which version of
1118
     GDB you are running; as GDB evolves, new commands are introduced,
1119
     and old ones may wither away.  Also, many system vendors ship
1120
     variant versions of GDB, and there are variant versions of GDB in
1121
     GNU/Linux distributions as well.  The version number is the same
1122
     as the one announced when you start GDB.
1123
 
1124
`show copying'
1125
     Display information about permission for copying GDB.
1126
 
1127
`show warranty'
1128
     Display the GNU "NO WARRANTY" statement, or a warranty, if your
1129
     version of GDB comes with one.
1130
 
1131

1132
File: gdb.info,  Node: Running,  Next: Stopping,  Prev: Commands,  Up: Top
1133
 
1134
Running Programs Under GDB
1135
**************************
1136
 
1137
   When you run a program under GDB, you must first generate debugging
1138
information when you compile it.
1139
 
1140
   You may start GDB with its arguments, if any, in an environment of
1141
your choice.  If you are doing native debugging, you may redirect your
1142
program's input and output, debug an already running process, or kill a
1143
child process.
1144
 
1145
* Menu:
1146
 
1147
* Compilation::                 Compiling for debugging
1148
* Starting::                    Starting your program
1149
* Arguments::                   Your program's arguments
1150
* Environment::                 Your program's environment
1151
 
1152
* Working Directory::           Your program's working directory
1153
* Input/Output::                Your program's input and output
1154
* Attach::                      Debugging an already-running process
1155
* Kill Process::                Killing the child process
1156
 
1157
* Threads::                     Debugging programs with multiple threads
1158
* Processes::                   Debugging programs with multiple processes
1159
 
1160

1161
File: gdb.info,  Node: Compilation,  Next: Starting,  Up: Running
1162
 
1163
Compiling for debugging
1164
=======================
1165
 
1166
   In order to debug a program effectively, you need to generate
1167
debugging information when you compile it.  This debugging information
1168
is stored in the object file; it describes the data type of each
1169
variable or function and the correspondence between source line numbers
1170
and addresses in the executable code.
1171
 
1172
   To request debugging information, specify the `-g' option when you
1173
run the compiler.
1174
 
1175
   Many C compilers are unable to handle the `-g' and `-O' options
1176
together.  Using those compilers, you cannot generate optimized
1177
executables containing debugging information.
1178
 
1179
   GCC, the GNU C compiler, supports `-g' with or without `-O', making
1180
it possible to debug optimized code.  We recommend that you _always_
1181
use `-g' whenever you compile a program.  You may think your program is
1182
correct, but there is no sense in pushing your luck.
1183
 
1184
   When you debug a program compiled with `-g -O', remember that the
1185
optimizer is rearranging your code; the debugger shows you what is
1186
really there.  Do not be too surprised when the execution path does not
1187
exactly match your source file!  An extreme example: if you define a
1188
variable, but never use it, GDB never sees that variable--because the
1189
compiler optimizes it out of existence.
1190
 
1191
   Some things do not work as well with `-g -O' as with just `-g',
1192
particularly on machines with instruction scheduling.  If in doubt,
1193
recompile with `-g' alone, and if this fixes the problem, please report
1194
it to us as a bug (including a test case!).
1195
 
1196
   Older versions of the GNU C compiler permitted a variant option
1197
`-gg' for debugging information.  GDB no longer supports this format;
1198
if your GNU C compiler has this option, do not use it.
1199
 
1200

1201
File: gdb.info,  Node: Starting,  Next: Arguments,  Prev: Compilation,  Up: Running
1202
 
1203
Starting your program
1204
=====================
1205
 
1206
`run'
1207
`r'
1208
     Use the `run' command to start your program under GDB.  You must
1209
     first specify the program name (except on VxWorks) with an
1210
     argument to GDB (*note Getting In and Out of GDB: Invocation.), or
1211
     by using the `file' or `exec-file' command (*note Commands to
1212
     specify files: Files.).
1213
 
1214
   If you are running your program in an execution environment that
1215
supports processes, `run' creates an inferior process and makes that
1216
process run your program.  (In environments without processes, `run'
1217
jumps to the start of your program.)
1218
 
1219
   The execution of a program is affected by certain information it
1220
receives from its superior.  GDB provides ways to specify this
1221
information, which you must do _before_ starting your program.  (You
1222
can change it after starting your program, but such changes only affect
1223
your program the next time you start it.)  This information may be
1224
divided into four categories:
1225
 
1226
The _arguments._
1227
     Specify the arguments to give your program as the arguments of the
1228
     `run' command.  If a shell is available on your target, the shell
1229
     is used to pass the arguments, so that you may use normal
1230
     conventions (such as wildcard expansion or variable substitution)
1231
     in describing the arguments.  In Unix systems, you can control
1232
     which shell is used with the `SHELL' environment variable.  *Note
1233
     Your program's arguments: Arguments.
1234
 
1235
The _environment._
1236
     Your program normally inherits its environment from GDB, but you
1237
     can use the GDB commands `set environment' and `unset environment'
1238
     to change parts of the environment that affect your program.
1239
     *Note Your program's environment: Environment.
1240
 
1241
The _working directory._
1242
     Your program inherits its working directory from GDB.  You can set
1243
     the GDB working directory with the `cd' command in GDB.  *Note
1244
     Your program's working directory: Working Directory.
1245
 
1246
The _standard input and output._
1247
     Your program normally uses the same device for standard input and
1248
     standard output as GDB is using.  You can redirect input and output
1249
     in the `run' command line, or you can use the `tty' command to set
1250
     a different device for your program.  *Note Your program's input
1251
     and output: Input/Output.
1252
 
1253
     _Warning:_ While input and output redirection work, you cannot use
1254
     pipes to pass the output of the program you are debugging to
1255
     another program; if you attempt this, GDB is likely to wind up
1256
     debugging the wrong program.
1257
 
1258
   When you issue the `run' command, your program begins to execute
1259
immediately.  *Note Stopping and continuing: Stopping, for discussion
1260
of how to arrange for your program to stop.  Once your program has
1261
stopped, you may call functions in your program, using the `print' or
1262
`call' commands.  *Note Examining Data: Data.
1263
 
1264
   If the modification time of your symbol file has changed since the
1265
last time GDB read its symbols, GDB discards its symbol table, and
1266
reads it again.  When it does this, GDB tries to retain your current
1267
breakpoints.
1268
 
1269

1270
File: gdb.info,  Node: Arguments,  Next: Environment,  Prev: Starting,  Up: Running
1271
 
1272
Your program's arguments
1273
========================
1274
 
1275
   The arguments to your program can be specified by the arguments of
1276
the `run' command.  They are passed to a shell, which expands wildcard
1277
characters and performs redirection of I/O, and thence to your program.
1278
Your `SHELL' environment variable (if it exists) specifies what shell
1279
GDB uses.  If you do not define `SHELL', GDB uses the default shell
1280
(`/bin/sh' on Unix).
1281
 
1282
   On non-Unix systems, the program is usually invoked directly by GDB,
1283
which emulates I/O redirection via the appropriate system calls, and
1284
the wildcard characters are expanded by the startup code of the
1285
program, not by the shell.
1286
 
1287
   `run' with no arguments uses the same arguments used by the previous
1288
`run', or those set by the `set args' command.
1289
 
1290
`set args'
1291
     Specify the arguments to be used the next time your program is
1292
     run.  If `set args' has no arguments, `run' executes your program
1293
     with no arguments.  Once you have run your program with arguments,
1294
     using `set args' before the next `run' is the only way to run it
1295
     again without arguments.
1296
 
1297
`show args'
1298
     Show the arguments to give your program when it is started.
1299
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.