gdb用户手册.doc

GDB用户手册目录目录1摘要2自由软件2自由软件急需自由文档2GDB的贡献者们41一个简单的GDB会话82征服GDB的进与出132.1调用GDB132.1.1 选择文件142.1.2 选择模式162.1.3 启动期间，GDB做了什么192.2 退出GDB202.3 Shell命令212.4 Loging输出213GDB命令223.1命令语法223.2命令完成233.3获得帮助254在GDB下运行程序294.1 适合调试的编译294.2 启动程序304.3 程序的参数324.4 程序的环境324.5 程序的工作目录344.6 程序的输入输出354.7 调试某个已运行的进程364.8 杀掉子进程374.9 多线程程序的调试374.10 多进程程序的调试405.0停止与继续42摘要象GDB这样的调试程序，目的就是让你可以查看其它程序的内部运行过程，或者是在它崩溃的那一时刻它在做什么。GDB能做4件事（这些还需附加其他的一些事），帮助你捕获在场的错误：·启动程序，设定任何可以影响它行为的东西。·在特定的条件下使程序停止。·当程序停止时，分析发生了什么。·改变程序里的一些东西，进行一个由于bug所导致的结果的矫正性试验，同时继续了解另外一个bug。可以使用GDB调试用C和C+编写的程序，更多信息参见支持的语言，及C与C+。部分支持Modula-2，Modula-2的更多信息参见Modula-2。在调试使用sets、subranges、file variables或嵌套函数的Pascal程序时，目前不能工作。GDB不支持entering expressions、printing values或者类似特性的Pascal语法。GDB可以调试Fortran写的程序，尽管那必然会涉及到带有下划线后缀的一些变量。GDB可以调试Objective-C写的程序，既可以使用Apple/NeXT运行时库，也可以使用GNU Objective-C运行时库。自由软件GDB是自由软件，受GNU公共许可证（GPL）保护。GPL给予了你自由复制或改编程序的许可就是说获得拷贝的人也就获得了自由修改它的权利（这意味着他们必须有权访问源代码），而且可以自由的发布更多的拷贝。大部分软件公司所使用的版权限制了你的自由。自由软件基金会利用GLP保护了这些自由。基本上来说，公共许可证是一个说明你拥有这些自由的许可证，而且你不能把这些自由从任何人那里占为己有。自由软件急需自由文档当今的自由软件社区所存在的最大缺憾不在于软件而在于没有我们可以随同自由软件包含在一起的好文档。好多我们十分重要的程序没有一同提供自由的参考指南和介绍性文本。对任何一个软件包来说，文档是最基本的部分。当一个重要的自由软件包没有与一个自由手册或指南一同提供时，那就是一个极大的缺憾。如今，我们拥有太多这样的缺憾了！拿Perl来说，人们日常所使用的指导手册就不是免费的。为什么会这样呢？因为这些手册的作者们在发表它们的时候伴有很多限制项目不能复制、不能修改、不能得到源文件把它们从自由软件世界中驱逐出去了。这类的事情已经不只发生过一次了，而且今后还会陆续发生。我们经常听到某位热心的GNU用户说他正在编写的一个手册，他打算把它捐献给社区，可没想到他签署了出版合同而使这个手册不自由了，所有的期望全都破灭。自由文档，就像自由软件一样，是自由的，不需要付费的东西。非自由手册的问题不在于发行商为印刷拷贝所要承担的费用只要它本身很好就行（自由软件基金会也出售印刷拷贝），而在于这个问题会约束手册的利用。自由手册可以以源代码的方式获得，允许复制与修改。非自由手册是不允许这么做的。自由文档自由度的标准，一般来说与自由软件差不多。再发布（包括很多常规的商业再发布）必须被允许，不管是以在线形式还以书面形式，以便手册可以伴随着程序的每一份拷贝。允许有关技术性方面的内容的更正也是至关重要的。当人们更改软件，添加或改变其某些特性时，如果他们负责任的话，也将会修改相应的手册因而，他们能够为修改过的程序提供准确而清晰的文档。某个手册的页数你是无法决定的，但是为某个程序的变更版本写一份全新的手册，对于我们的社区来说，那真是没有必要。在改进过程中所运用的某些限制是合理的。例如，要求保持原作者的版权通告、发布条款、以及作者名单，是没有问题的。在修正版本中包含是他们更正的通告也是没有问题的。只要论述的是非技术性的话题（就像这一章），可以接受连续完整的章节不可删除或被更改。能够接受这些限制，是因为它们不会妨碍社区对手册的正常使用。无论如何，必须允许对手册中所有关技术性方面的内容进行修改，然后通过所有正常的通道，利用所有常规的媒质，发布这个结果。否则，这些限制就妨碍了对手册的使用，那么它就是非自由的了，我们就得需要一个新的手册来代替它了。请散布有关这一论点的言辞。我们的社区仍然在遗失好多手册，这些手册都在成为私有出版物。如果我们趁早散布自由软件急需自由参考手册和指南这样的言辞的话，也许下一个投稿人就会意识到，只有少数的手册投稿给了自由软件社区。如果你正在撰写文档，请坚持在GNU的自由文档许可证或其他的自由许可证下出版它。别忘了，这个决策是需要争得你的赞同的你不用理会出版社的决策。只要你坚持，某些出版社会使用自由许可证的，但是他们不能奢求有买卖的特权；那需要由你自己来发行，并且坚定地说：这就是你想要的。如果这个出版社拒绝了你的生意，那就再换一家。如果你不能确定某个被提议的许可证是自由的，就写信给licensinggnu.org。你可以使用购买的方式来鼓励商业出版社出售更多的免费的，非赢利版权的手册与指南，尤其是购买那些来自于出版社的拷贝，付给他们撰写或作重大改进的费用。同时，尽量完全避免购买非自由的文档。在购买之前，先查看一下发布条款，不管谁要做你的生意都必须尊重你的自由。查看书的历史，设法奖励支付了作者们工资的那些出版社。自由软件基金会在http:/www.fsf.org/doc/other-free-books.html维护了一个已经由其他一些出版社出版了的文档的列表。GDB的贡献者们Richard Stallman是GDB的原作者，也是其他好多GNU程序的原作者。好多人已经对它的开发作了贡献。谨以此节来表彰那些主要的贡献者们。自由软件的一个优点就是每个人都无偿的为它作贡献。遗憾的是，我们无法逐一向他们表示感谢。在GDB的发布中，有一个“ChangeLog”文件，做了极为详尽的说明。2.0版本以前的大量变化已湮灭在时间的迷雾中。恳请：极力欢迎对本节的补充。如果您或您的朋友（或者是敌人，为了公平），不公平地在这个列表中被遗漏了，我们愿意加入您的名字。为了使那些可能被遗忘的人们的工作不至于徒劳无功，在此特别感谢那些带领GDB走过各个重要发布版的那些人：Andrew Cagney（发布了6.1, 6.0, 5.3, 5.2, 5.1 和5.0版）；Jim Blandy（发布了4.18版）；Jason Molenda（发布了4.17版）；Stan Shebs（发布了4.14版）；Fred Fish （发布了 4.16，4.15，4.13，4.12，4.11，4.10和4.9）；Stu Grossman 和John Gilmore （发布了4.8，4.7，4.6，4.5和4.4版)；John Gilmore（发布了4.3，4.2，4.1，4.0和3.9版）；Jim Kingdon（发布了3.5，3.4和3.3版）；以及Randy Smith（发布了3.2，3.1和3.0）。Richard Stallman，在Peter TerMaat、Chris Hanson、和Richard Mlynarik的多次协助下，完成到了2.8版的发布。Michael Tiemann是GDB中大部分GNU C+支持的作者，得益于来自Per Bothner 和Daniel Berlin的其他的一些重要贡献。James Clark编写了GNU C+反签名编码器（demangler）。早期在C+方面的工作是由Peter TerMaat做的（他也做了大量的到3.0发布版的常规更新工作）。GDB是使用BFD子程序库来分析多种目标文件格式的，BFD是David V. Henkel-Wallace、Rich Pixley、Steve Chamberlain和John Gilmore的一个合作项目。David Johnson编写了最初的COFF支持。Pace Willison做了最初的压缩的COFF支持。哈里斯计算机系统（Harris Computer Systems）的Brent Benson贡献了DWARF 2的支持。Adam de Boor 和Bradley Davis贡献了ISI Optimum V的支持。Per Bothner、Noboyuki Hikichi和Alessandro Forin 贡献了MIPS的支持。Jean-Daniel Fekete贡献了Sun 386i的支持。Chris Hanson改良了HP9000的支持。Noboyuki Hikichi和Tomoyuki Hasei贡献了Sony/News OS 3的支持。David Johnson贡献了Encore Umax的支持。Jyrki Kuoppala贡献了Altos 3068的支持。Jeff Law贡献了HP PA和SOM的支持。Keith Packard贡献了NS32k的支持。Doug Rabson贡献了Acorn Risc Machine的支持。Bob Rusk贡献了Harris Nighthawk CX-UX的支持。Chris Smith贡献了Convex的支持（还有Fortran的调试）。Jonathan Stone贡献了Pyramid的支持。Michael Tiemann贡献了SPARC的支持。Tim Tucker贡献了对Gould NP1和Gould Powernode的支持。Pace Willison贡献了Intel 386的支持。Jay Vosburgh贡献了Symmetry的支持。Marko Mlinar贡献了OpenRISC 1000的支持。Andreas Schwab贡献了M68k GNU/Linux的支持。Rich Schaefer 和Peter Schauer为支持SunOS的共享库提供了帮助。Jay Fenlason和Roland McGrath保证了GDB和GAS适用于若干机器指令集。Patrick Duval、Ted Goldstein、Vikram Koka和Glenn Engel帮助开发了远程调试。Intel 公司、风河系统（Wind River Systems）、AMD、以及ARM 分别贡献了i960、VxWorks、A29K UDI和RDI targets的远程调试模块。Brian Fox，readline库的作者，正在提供命令行编辑与命令历史功能。SUNY Buffalo的Andrew Beers编写了语言切换代码、Modula-2的支持，并且贡献了此手册的语言一章。Fred Fish做了支持Unix System Vr4的大部分编写工作。他也增强了command-completion的支持，使其覆盖到了C+的过载符号。Hitachi America (现在是Renesas America), Ltd。负责了对H8/300、H8/500和Super-H处理器的支持。NEC负责了对v850、Vr4xxx和Vr5xxx处理器的支持。Mitsubishi（现在是Renesas）负责了对D10V、D30V和M32R/D处理器的支持。Toshiba负责了对TX39 Mips处理器的支持。Matsushita负责了对MN10200和MN10300处理器的支持。Fujitsu负责了对SPARClite和FR30处理器的支持。Kung Hsu、Jeff Law和Rick Sladkey添加了对硬件监视点（hardware watchpoints）的支持。Michael Snyder添加了对跟踪点（tracepoints）的支持。Stu Grossman编写了gdbserver。Jim Kingdon、Peter Schauer、Ian Taylor、及Stu Grossman，修复了几乎数不清的bug，并且对整个GDB做了清理。惠普公司（Hewlett-Packard Company）的一些人贡献了对PA-RISC 2.0体系、HP-UX 10.20、10.30和11.0 (窄模式)、HP的内核执行线程、HP的aC+编译器、以及文本用户界面（旧称终端用户界面）的支持。他们是：Ben Krepp、Richard Title、John Bishop、Susan Macchia、 Kathy Mann、Satish Pai、India Paul、Steve Rehrauer和Elena Zannoni。Kim Haase提供了此手册中的HP-specific信息。DJ Delorie为DJGPP项目，把GDB移植到了MS-DOS上。Robert Hoehne对DJGPP的移植作了重大的贡献。Cygnus Solutions已负责起GDB的维护，自1991年以来已做了大量的开发工作。Cygnus为GDB做全职工作的工程师有：Mark Alexander、Jim Blandy、 Per Bothner、Kevin Buettner、 Edith Epstein、Chris Faylor、Fred Fish、Martin Hunt、Jim Ingham、John Gilmore、Stu Grossman、 Kung Hsu、Jim Kingdon、John Metzler、Fernando Nasser、Geoffrey Noer、Dawn Perchik、Rich Pixley、Zdenek Radouch、Keith Seitz、Stan Shebs、David Taylor和Elena Zannoni. 另外还有： Dave Brolley、Ian Carmichael、Steve Chamberlain、Nick Clifton、JT Conklin、Stan Cox、DJ Delorie、Ulrich Drepper、Frank Eigler、Doug Evans、Sean Fagan、David Henkel-Wallace、Richard Henderson、Jeff Holcomb、Jeff Law、Jim Lemke、Tom Lord、Bob Manson、Michael Meissner、Jason Merrill、Catherine Moore、Drew Moseley、Ken Raeburn、Gavin Romig-Koch、Rob Savoye、Jamie Smith、Mike Stump、Ian Taylor、Angela Thomas、Michael Tiemann、Tom Tromey、Ron Unrau、Jim Wilson和David Zuhn，他们做了大大小小不同的贡献。Andrew Cagney、Fernando Nasser和 Elena Zannoni，他们在Cygnus Solutions工作时，实现了最初GDB/MI接口。Jim Blandy添加了预处理宏的支持，那时他在Red Hat工作。Andrew Cagney设计了GDB的结构向量。包括Andrew Cagney、Stephane Carrez、Randolph Chung、Nick Duffek、Richard Henderson、Mark Kettenis、Grace Sainsbury、Kei Sakamoto、Yoshinori Sato、Michael Snyder、Andreas Schwab、Jason Thorpe、Corinna Vinschen、Ulrich Weigand和Elena Zannoni的很多人，为把旧有的体系结构移植到这个新的框架上提供了帮助。请发送FSF和GNU的疑问和问题到gnugnu.org。这也有一些其他的方式联系FSF。这些页面是由GDB的开发者们维护的。Copyright Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.。只要保留这些信息，以任何媒质，一字不差地复制与分者这一整份文章是允许的。本文是由GDB的管理员于2005年7月16日，使用text2html生成的。1一个简单的GDB会话你可以在你的业余时间利用本手册了解有关GDB的一切。可是，少数几个命令，就足以开始使用调试器了。本章就阐明了那些命令。GNU m4（一个普通的宏处理器）的一个初级版本表现出下列bug：有些时候，当我们改变它默认的引证串（quote string，译者注：也就是我们常说的引号）时，用于捕获一个在别处定义的宏的命令停止工作。在下列简短的m4会话中，我们定一个可扩展为0000的宏；然后我们利用m4內建的defx定义一个相同的东西bar。可是当我们把左引证串(open quote string，译者注：英文直译为开引证串)改为<QUOTE>，右引证串（close quote string）改为<UNQUOTE>时，相同的程序不能定义新的替代名baz：$cd gnu/m4$./m4define(foo,0000)foo0000define(bar,defn(foo')bar0000changequote(<QUOTE>,<UNQUOTE>)define(baz,defn(<QUOTE>foo<UNQUOTE>)bazC-dm4: End of input: 0: fatal error: EOF in string让我们利用GDB设法看一下发生了什么事。$gdb m4GDB is free software and you are welcome to distribute copiesof it under certain conditions; type "show copying" to see the conditions.There is absolutely no warranty for GDB; type "show warranty"for details.GDB 6.3.50.20050716, Copyright 1999 Free Software Foundation, Inc.(gdb)GDB仅读取足够查找所需的符号数据，余下的按需读取。结果是，第一提示很快就出现了。我们告诉GDB使用一个比平常要窄的显示宽度，以使样例与本手册相适应。（gdb）set width 70我们要看一下m4內建的changequote是如何工作的。通过查看源代码，我们了解到与其相关的子程序是m4_changequote，因此我们使用GDB的break命令在那里设置了一个断点。（gdb）break m4_changequoteBreakpoint 1 at 0x62f4: file builtin.c, line 879.使用run命令，在GDB的控制下，我们开始了m4的运行。只要控制没有到达m4_changequote子程序，程序就会像平常那样运行。（gdb）runStarting program: /work/Editorial/gdb/gnu/m4/m4define(foo,0000)foo0000为了引发断点，我们调用changequote。GDB暂停执行m4，显示中断处的上下文信息。changequote(<QUOTE>,<UNQUOTE>)Breakpoint 1, m4_changequote (argc=3, argv=0x33c70) at builtin.c:879879 if (bad_argc(TOKEN_DATA_TEXT(argv0),argc,1,3)现在，我们使用命令n（next）向前执行到当前函数的下一行。(gdb) n882 set_quotes(argc >= 2) ? TOKEN_DATA_TEXT(argv1) : nil,set_quotes像是一个有希望的子程序。我们可以使用命令s（step）代替next进入到他的里面。Step转到任意子程序中要被执行的下一行，因此他进入了set_quotes。（gdb）sset_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "") at input.c:530530 if (lquote != def_lquote)显示器显示了目前m4所停在子程序（还有它的参数）的被调堆栈帧的展示。它显示了一个堆栈的摘要信息。我们可以使用backtrace命令（也可以被拼写为bt）,查看总体上我们在堆栈上的位置：Backtrace显示了每一个活动子程序的堆栈帧。(gdb) bt#0 set_quotes (lq=0x34c78 "<QUOTE>", rq=0x34c88 "") at input.c:530#1 0x6344 in m4_changequote (argc=3, argv=0x33c70) at builtin.c:882#2 0x8174 in expand_macro (sym=0x33320) at macro.c:242#3 0x7a88 in expand_token (obs=0x0, t=209696, td=0xf7fffa30) at macro.c:71#4 0x79dc in expand_input () at macro.c:40#5 0x2930 in main (argc=0, argv=0xf7fffb20) at m4.c:195我们向前单步调试更多的行，看看都发生了什么。前两次我们使用“s”；后两次为了避免陷入xstrdup子程序我们使用“n”。(gdb) s0x3b5c 532 if (rquote != def_rquote)(gdb) s0x3b80 535 lquote = (lq = nil | *lq = '0') ? def_lquote : xstrdup(lq);(gdb) n536 rquote = (rq = nil | *rq = '0') ? def_rquote : xstrdup(rq);(gdb) n538 len_lquote = strlen(rquote);最后以行看起来有点古怪；我们能够检查变量lquote和rquote，看看他们现在是不是我们新指定的左右引号。我们使用命令p来查看它们的值。（gdb）p lquote$1 = 0x35d40 "<QUOTE>"（gdb）p rquote$2 = 0x35d50 "<UNQUOTE>"Lquote和rquote的确是新的左右引号。为了能够查看上下文，我们可以使用l（list）命令，围绕着当前行，显示十行源代码。(gdb) l533 xfree(rquote);534535 lquote = (lq = nil | *lq = '0') ? def_lquote : xstrdup (lq);536 rquote = (rq = nil | *rq = '0') ? def_rquote : xstrdup (rq);537538 len_lquote = strlen(rquote);539 len_rquote = strlen(lquote);540 541542 void让我们单步执行，通过设置len_lquote和len_rquote的那两行，然后查看一下它们的值。（gdb）n539 len_rquote = strlen(lquote);（gdb）n540 （gdb）p len_lquote$3 = 9(gdb) p len_rquote$4 = 7假设len_lquote和len_rquote分别代表lquote和rquote的长度的话，那显然就是错的。我们能够利用p命令给它们设定更好的值，因为它可以打印任何表达式的值表达式中还可以有子程序调用并赋值。(gdb) p len_lquote=strlen(lquote)$5 = 7(gdb) p len_rquote=strlen(rquote)$6 = 9那足以修复与m4內建的defn一同使用新引号的问题吗？我们可以使用c（continue）命令使m4继续执行，然后试试刚开始时那个有问题的例子：(gdb) cContinuing.define(baz,defn(<QUOTE>foo<UNQUOTE>)baz0000成功了！新的引号已经可以象默认的一样工作了。问题看来就是两个输入错误导致了错误的长度计算造成的。我们输入一个EOF让m4退出。C-dProgram exited normally.“Program exited normally”是GDB发出的。它表明m4已经结束执行了。我们可以使用GDB的quit命令结束我们的GDB会话。(gdb) quit2征服GDB的进与出本章讨论如何启动GDB，并且如何离开GDB。要点为：l 输入“gdb”启动GDBl 输入quit或C-d退出GDB2.1调用GDB如何启动GDB2.2退出GDB如何退出GDB2.3 Shell命令如何在GDB中使用Shell命令2.4 Loging输出如果把GDB的输出记录成为一个文件2.1调用GDB通过运行gdb程序来调用GDB。一旦启动，GDB就开始从终端读取命令，直到你让它退出为止。你也可以使用多种参数与选项来运行gdb，在一开始就能更多地为您定义调试环境。对于命令行选项的描述，这里打算覆盖多种情况。在一些环境中，某些选项可能会不起作用。启动GDB最常用的方法是使用一个参数，指定一个可执行程序：gdb program也可以指定一个可执行程序和一个core文件一起启动gdb：gdb program core如果你想调试一个运行中的程序，作为代替，你可以指定一个进程ID为第二个参数：gdb program 1234将把GDB附着到进程1234（除非你也有一个名叫“1234”的文件；GDB总是先检查core文件）。运动第二个命令行参数需要一个相当完整的操作系统；当我们利用GDB作为远程调试器附着到一个裸板上时，那里可能没有任何“进程”的概念，那也就常常无法获得core dump。如果GDB没有能力附着或读取core dumps时，它会发出警告。可以使用-args选项，给gdb要调试的程序传递参数。这一选项使gdb的选项处理停止。gdb args gcc -O2 -c foo.c这使得gdb调试gcc，并给gcc传递命令行参数（见4.3程序的参数一节）“-O2 -c foo.c”。可以通过指定-silent选项，运行gdb而不打印前面的资料，这些资料说明GDB不作任何担保。gdb silent你可以通过设定命令行选项，更多地控制GDB的启动。GDB自身就能够给你各种可用选项的提示。输入gdb help显示所有可用选项，并对它们的用法作了简短的描述（可以简写成gdb h，作用相同）。所有的选项和命令行参数按照你所给的顺序进行处理。当使用“-x”选项时，顺序就就比较重要了。2.1.1 选择文件2.1.2 选择模式2.1.3 启动期间，GDB做了什么2.1.1 选择文件在GDB启动时，除了选项之外，它把所有的参数都看作是可执行文件和core文件（或者是进程ID）来读取。就如同这些参数已分别被“-se”和“-c”（或者是“-p”）选项所修饰过一样。（GDB读取的第一个参数，如果没有关联的选项标志，就等同于“-se”选项后面参数；如果有第二个这样的参数的话，就等同于“-c”/“-p”选项后的参数）如果第二个参数是以一个10进制数开头的话，GDB首先会尝试把它作为一个进程去附着，如果失败了的话，就尝试着把它作为core文件打开。如果有一个文件名以数字开头的core文件的话，可用通过附加./前缀来避免GDB把它当成pid，如./12345。如果GDB已经被配置为不支持core文件，比如大部分的嵌入式目标，它将拒绝第二个参数而忽略它。大部分的选项都有长格式和短格式；都被展示在下表中。GDB也能识别不完整的长格式，只要与给出的各个选项之间没有歧义就行。（如果你愿意，你可以使用“-”来标记选项参数，而不用“-”，虽然我们展示的是更常用的约定）。-symbols file -s file 从文件file中读取符号表。-exec file -e file 把文件file当作可执行文件来使用，在适当的时候执行，连同core dump，分析单纯的数据。-se file从文件file中读取符号表，并把它当作可执行文件来使用。-core file -c file 把文件file当成core文件使用，进行分析。-c number -pid number -p number同附着命令一样，连接到一个进程ID number。如果没有这个进程，GDB就尝试着打开一个名为number的core文件。-command file -x file执行文件file中的GDB命令。参见命令文件一章-directory directory -d directory添加directory到原文件搜索路径。-m -mapped警告：这个选项依赖于操作系统的功能，并不被所有的操作系统所支持。如果你的操作系统可以通过mmap系统调用使用内存映射文件（memory-mapped files），你就可以利用这个选项，让GDB把你程序的符号写到当前目录下的一个可重用文件（reusable file）中。如果你正调试程序是“/tmp/fred”，那么对应的符号文件就是“/tmp/fred.syms”。之后的GDB调试会话会注意这个文件的存在，并且快速的映射它的符号信息，而不需要从可执行程序的符号表中读取。“.syms”文件特属于GDB所运行的主机。它保存着GDB内部符号表的精确映像。它不能被多个主机平台交叉共享。-r -readnow立即读取每一个符号文件的整个符号表，不同于默认的根据需要而逐步读取。这使得启动会更慢，但之后的操作会更快。为了创建一个包换完整符号信息的“.syms”文件，典型的做法是-mapped与-readnow联合使用（参见文件指定命令一章，有关“.syms”文件的资料）。一个简单的创建一个“.symes”文件以便以后使用的GDB调用是：gdb -batch -nx -mapped -readnow programname2.1.2 选择模式可以以两种模式中的一种运行GDB批处理模式或单调模式。-nx-n不执行在任何初始化文件中找到的命令。默认情况下，GDB会在处理完所有命令选项与参数之后执行这些文件里的命令。参见命令文件一章。-quiet -silent -q “单调”。不打印介绍性信息和版权信息。这些信息在批处理模式下也是不打印的。-batch以批处理模式运行。处理完所有由“-x”所指定的命令文件（如果不使用“-n”来约束，还有所有的初始化文件）后以状态0退出。在执行命令文件中的命令过程中，如果发生错误，则以非0状态退出。GDB作为一个过滤器运行时，批处理模式可能会有用，例如，在另外一台计算机上下载并运行一段程序；为了使这个更有用，消息Program exited normally.(只要程序是在GDB的控制下运行终止的，一般都会使这个结果)说明批处理模式下的运行是没有问题。-nowindows -nw“无窗口”。倘若GDB伴随有一个图形用户界面（GUI），这时这个选项就告诉GDB仅使用命令行界面。如果没有GUI可用，这个选项也就没有作用。-windows -w 如果GDB含有一个GUI的话，那么这个选项就是请求：如果可能的话，就使用它。-cd directory用directory代替当前的目录，作为GDB的运行工作目录运行。-fullname -f当GDB作为GNU Emacs的子进程运行时，设置这个选项。他告诉GDB以某一标准输出完整的文件名和行号，以便每次都能以大家公认方式显示栈结构（这也包括每次程序停止时）。这个公认的格式为：两个“032”字符后面跟着一个文件名，行号和字符位置以颜色区分，外加一个换行。Emacs-to-GDB的接口程序利用两个“032”字符作为显示栈结构源代码的信号。-epoch当GDB作为Epoch Emacs-GDB接口的子进程运行时，设置这个选项。它告诉GDB修改它的打印程序，以便Epoch可以在分割窗口中显示表达式的值。-annotate level这个选项设置GDB内部的注释级别。它的作用和使用“set annotate leave”相同（参见25.GDB的注释一章）。注释级别控制着应有多少消息同GDB的提示符一起打印，这些信息有：表达式的值、源代码行数以及其他类型的一些输出。级别0是默认级别，级别1用于GDB作为Emacs的子进程时，级别3是最大量的在GDB控制下的程序的相关信息，级别2现在已经不被建议使用了。这个注释机制在很大程度上已被GDB/MI所代替（参见24.GDB/IM接口一章）。-args改变对命令行的解释，以使可执行文件的参数可以被作为命令行参数传给它。这个选项阻止选项处理。-baud bps -b bps设置任一用于GDB远程调试的串行接口的线速度。-l timeout设置任一用于GDB远程调试的通讯的超时值（以秒为单位）。-tty