GDB调试指南：深入探索程序错误

4星 · 超过85%的资源需积分: 10 124 浏览量更新于2024-07-30 1 收藏 1.87MB PDF 举报

"《Debugging with GDB》是GDB调试手册的第十版，针对GDB版本7.3.1.20111020编写，由Richard Stallman、Roland Pesch、Stan Shebs等人合著，并且鼓励用户在遇到问题时通过指定网址向开发团队反馈。这本书共有580页，详细介绍了GDB的使用方法，适用于对GDB有深入研究的人员以及初学者。GDB是GNU开源组织提供的源代码级调试器，广泛用于C、C++等语言的程序调试。" GDB（GNU调试器）是软件开发过程中的重要工具，它允许程序员在运行时检查和控制程序，帮助找出和修复代码中的错误。以下是GDB的一些核心功能和概念： 1. 设置断点: 在特定行或条件满足时暂停程序执行，以便检查此时的程序状态，如变量值、内存布局等。 2. 单步执行: 逐行执行代码，便于观察每一步的变化，了解程序流程。 3. 查看变量: 查看当前作用域内的变量值，也可以监视变量值的变化。 4. 堆栈跟踪: 显示调用栈，帮助理解函数调用关系，找出问题的来源。 5. 内存操作: 查看和修改内存中的数据，这对于分析内存泄漏或指针错误等问题非常有用。 6. 调用函数: 直接在调试器中调用函数，无需运行整个程序。 7. 运行时错误检测: GDB支持对一些常见的运行时错误进行检测，如除以零、非法内存访问等。 8. 远程调试: 支持通过网络连接远程调试目标系统上的程序。 9. 多线程调试: 能够同时管理并调试多线程程序中的各个线程。 10. 脚本支持: 可以通过Python等语言编写自定义脚本，扩展GDB的功能。 11. GDB服务器: 在嵌入式设备或远程主机上运行GDB服务器，本地GDB客户端可以连接到服务器进行调试。学习和掌握GDB，不仅可以提升调试效率，还能加深对程序执行的理解。《Debugging with GDB》这本书通过实例和详尽的解释，将帮助读者熟练掌握这些技能，无论是新手还是经验丰富的开发者，都能从中获益。在阅读过程中，读者会了解到如何有效地利用GDB的特性来定位和解决问题，从而提高编程质量和效率。

Summary of gdb 1

Summary of gdb

The purpose of a debugger such as gdb is to allow you to see what is going on “inside”

another program while it executes—or what another program was doing at the moment it

crashed.

gdb can do four main kinds of things (plus other things in support of these) to help you

catch bugs in the act:

• Start your program, specifying anything that might aﬀect its behavior.

• Make your program stop on speciﬁed conditions.

• Examine what has happened, when your program has stopped.

• Change things in your program, so you can experiment with correcting the eﬀects of

one bug and go on to learn about another.

You can use gdb to debug programs written in C and C++. For more information, see

Section 15.4 [Supported Languages], page 159. For more information, see Section 15.4.1 [C

and C++], page 159.

Support for D is partial. For information on D, see Section 15.4.2 [D], page 165.

Support for Modula-2 is partial. For information on Modula-2, see Section 15.4.7

[Modula-2], page 168.

Support for OpenCL C is partial. For information on OpenCL C, see Section 15.4.4

[OpenCL C], page 166.

Debugging Pascal programs which use sets, subranges, ﬁle variables, or nested functions

does not currently work. gdb does not support entering expressions, printing values, or

similar features using Pascal syntax.

gdb can be used to debug programs written in Fortran, although it may be necessary

to refer to some variables with a trailing underscore.

gdb can be used to debug programs written in Objective-C, using either the Ap-

ple/NeXT or the GNU Objective-C runtime.

Free Software

gdb is free software, protected by the gnu General Public License (GPL). The GPL gives

you the freedom to copy or adapt a licensed program—but every person getting a copy also

gets with it the freedom to modify that copy (which means that they must get access to the

source code), and the freedom to distribute further copies. Typical software companies use

copyrights to limit your freedoms; the Free Software Foundation uses the GPL to preserve

these freedoms.

Fundamentally, the General Public License is a license which says that you have these

freedoms and that you cannot take these freedoms away from anyone else.

Free Software Needs Free Documentation

The biggest deﬁciency in the free software community today is not in the software—it is the

lack of good free documentation that we can include with the free software. Many of our

most important programs do not come with free reference manuals and free introductory

2 Debugging with gdb

texts. Documentation is an essential part of any software package; when an important free

software package does not come with a free manual and a free tutorial, that is a major gap.

We have many such gaps today.

Consider Perl, for instance. The tutorial manuals that people normally use are non-free.

How did this come about? Because the authors of those manuals published them with

restrictive terms—no copying, no modiﬁcation, source ﬁles not available—which exclude

them from the free software world.

That wasn’t the ﬁrst time this sort of thing happened, and it was far from the last.

Many times we have heard a GNU user eagerly describe a manual that he is writing, his

intended contribution to the community, only to learn that he had ruined everything by

signing a publication contract to make it non-free.

Free documentation, like free software, is a matter of freedom, not price. The problem

with the non-free manual is not that publishers charge a price for printed copies—that in

itself is ﬁne. (The Free Software Foundation sells printed copies of manuals, too.) The

problem is the restrictions on the use of the manual. Free manuals are available in source

code form, and give you permission to copy and modify. Non-free manuals do not allow

this.

The criteria of freedom for a free manual are roughly the same as for free software.

Redistribution (including the normal kinds of commercial redistribution) must be permitted,

so that the manual can accompany every copy of the program, both on-line and on paper.

Permission for modiﬁcation of the technical content is crucial too. When people mod-

ify the software, adding or changing features, if they are conscientious they will change

the manual too—so they can provide accurate and clear documentation for the modiﬁed

program. A manual that leaves you no choice but to write a new manual to document a

changed version of the program is not really available to our community.

Some kinds of limits on the way modiﬁcation is handled are acceptable. For example,

requirements to preserve the original author’s copyright notice, the distribution terms, or

the list of authors, are ok. It is also no problem to require modiﬁed versions to include

notice that they were modiﬁed. Even entire sections that may not be deleted or changed

are acceptable, as long as they deal with nontechnical topics (like this one). These kinds of

restrictions are acceptable because they don’t obstruct the community’s normal use of the

manual.

However, it must be possible to modify all the technical content of the manual, and then

distribute the result in all the usual media, through all the usual channels. Otherwise, the

restrictions obstruct the use of the manual, it is not free, and we need another manual to

replace it.

Please spread the word about this issue. Our community continues to lose manuals

to proprietary publishing. If we spread the word that free software needs free reference

manuals and free tutorials, perhaps the next person who wants to contribute by writing

documentation will realize, before it is too late, that only free manuals contribute to the

free software community.

If you are writing documentation, please insist on publishing it under the GNU Free

Documentation License or another free documentation license. Remember that this deci-

sion requires your approval—you don’t have to let the publisher decide. Some commercial

publishers will use a free license if you insist, but they will not propose the option; it is up

Summary of gdb 3

to you to raise the issue and say ﬁrmly that this is what you want. If the publisher you

are dealing with refuses, please try other publishers. If you’re not sure whether a proposed

license is free, write to licensing@gnu.org.

You can encourage commercial publishers to sell more free, copylefted manuals and

tutorials by buying them, and particularly by buying copies from the publishers that paid

for their writing or for major improvements. Meanwhile, try to avoid buying non-free

documentation at all. Check the distribution terms of a manual before you buy it, and

insist that whoever seeks your business must respect your freedom. Check the history of

the book, and try to reward the publishers that have paid or pay the authors to work on it.

The Free Software Foundation maintains a list of free documentation published by other

publishers, at http://www.fsf.org/doc/other-free-books.html.

Contributors to gdb

Richard Stallman was the original author of gdb, and of many other gnu programs. Many

others have contributed to its development. This section attempts to credit major contrib-

utors. One of the virtues of free software is that everyone is free to contribute to it; with

regret, we cannot actually acknowledge everyone here. The ﬁle ‘ChangeLog’ in the gdb

distribution approximates a blow-by-blow account.

Changes much prior to version 2.0 are lost in the mists of time.

Plea: Additions to this section are particularly welcome. If you or your friends

(or enemies, to be evenhanded) have been unfairly omitted from this list, we

would like to add your names!

So that they may not regard their many labors as thankless, we particularly thank those

who shepherded gdb through major releases: Andrew Cagney (releases 6.3, 6.2, 6.1, 6.0,

5.3, 5.2, 5.1 and 5.0); Jim Blandy (release 4.18); Jason Molenda (release 4.17); Stan Shebs

(release 4.14); Fred Fish (releases 4.16, 4.15, 4.13, 4.12, 4.11, 4.10, and 4.9); Stu Grossman

and John Gilmore (releases 4.8, 4.7, 4.6, 4.5, and 4.4); John Gilmore (releases 4.3, 4.2, 4.1,

4.0, and 3.9); Jim Kingdon (releases 3.5, 3.4, and 3.3); and Randy Smith (releases 3.2, 3.1,

and 3.0).

Richard Stallman, assisted at various times by Peter TerMaat, Chris Hanson, and

Richard Mlynarik, handled releases through 2.8.

Michael Tiemann is the author of most of the gnu C++ support in gdb, with signiﬁcant

additional contributions from Per Bothner and Daniel Berlin. James Clark wrote the gnu

C++ demangler. Early work on C++ was by Peter TerMaat (who also did much general

update work leading to release 3.0).

gdb uses the BFD subroutine library to examine multiple object-ﬁle formats; BFD was

a joint project of David V. Henkel-Wallace, Rich Pixley, Steve Chamberlain, and John

Gilmore.

David Johnson wrote the original COFF support; Pace Willison did the original support

for encapsulated COFF.

Brent Benson of Harris Computer Systems contributed DWARF 2 support.

Adam de Boor and Bradley Davis contributed the ISI Optimum V support. Per Bothner,

Noboyuki Hikichi, and Alessandro Forin contributed MIPS support. Jean-Daniel Fekete

contributed Sun 386i support. Chris Hanson improved the HP9000 support. Noboyuki

4 Debugging with gdb

Hikichi and Tomoyuki Hasei contributed Sony/News OS 3 support. David Johnson con-

tributed Encore Umax support. Jyrki Kuoppala contributed Altos 3068 support. Jeﬀ

Law contributed HP PA and SOM support. Keith Packard contributed NS32K support.

Doug Rabson contributed Acorn Risc Machine support. Bob Rusk contributed Harris

Nighthawk CX-UX support. Chris Smith contributed Convex support (and Fortran de-

bugging). Jonathan Stone contributed Pyramid support. Michael Tiemann contributed

SPARC support. Tim Tucker contributed support for the Gould NP1 and Gould Powern-

ode. Pace Willison contributed Intel 386 support. Jay Vosburgh contributed Symmetry

support. Marko Mlinar contributed OpenRISC 1000 support.

Andreas Schwab contributed M68K gnu/Linux support.

Rich Schaefer and Peter Schauer helped with support of SunOS shared libraries.

Jay Fenlason and Roland McGrath ensured that gdb and GAS agree about several

machine instruction sets.

Patrick Duval, Ted Goldstein, Vikram Koka and Glenn Engel helped develop remote

debugging. Intel Corporation, Wind River Systems, AMD, and ARM contributed remote

debugging modules for the i960, VxWorks, A29K UDI, and RDI targets, respectively.

Brian Fox is the author of the readline libraries providing command-line editing and

command history.

Andrew Beers of SUNY Buﬀalo wrote the language-switching code, the Modula-2 sup-

port, and contributed the Languages chapter of this manual.

Fred Fish wrote most of the support for Unix System Vr4. He also enhanced the

command-completion support to cover C++ overloaded symbols.

Hitachi America (now Renesas America), Ltd. sponsored the support for H8/300,

H8/500, and Super-H processors.

NEC sponsored the support for the v850, Vr4xxx, and Vr5xxx processors.

Mitsubishi (now Renesas) sponsored the support for D10V, D30V, and M32R/D proces-

sors.

Toshiba sponsored the support for the TX39 Mips processor.

Matsushita sponsored the support for the MN10200 and MN10300 processors.

Fujitsu sponsored the support for SPARClite and FR30 processors.

Kung Hsu, Jeﬀ Law, and Rick Sladkey added support for hardware watchpoints.

Michael Snyder added support for tracepoints.

Stu Grossman wrote gdbserver.

Jim Kingdon, Peter Schauer, Ian Taylor, and Stu Grossman made nearly innumerable

bug ﬁxes and cleanups throughout gdb.

The following people at the Hewlett-Packard Company contributed support for the PA-

RISC 2.0 architecture, HP-UX 10.20, 10.30, and 11.0 (narrow mode), HP’s implementation

of kernel threads, HP’s aC++ compiler, and the Text User Interface (nee Terminal User

Interface): Ben Krepp, Richard Title, John Bishop, Susan Macchia, Kathy Mann, Satish

Pai, India Paul, Steve Rehrauer, and Elena Zannoni. Kim Haase provided HP-speciﬁc

information in this manual.

DJ Delorie ported gdb to MS-DOS, for the DJGPP project. Robert Hoehne made

signiﬁcant contributions to the DJGPP port.

Summary of gdb 5

Cygnus Solutions has sponsored gdb maintenance and much of its development since

1991. Cygnus engineers who have worked on gdb fulltime include 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, Geoﬀrey Noer, Dawn Perchik, Rich Pixley, Zdenek Radouch, Keith Seitz,

Stan Shebs, David Taylor, and Elena Zannoni. In addition, 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, Jeﬀ Holcomb,

Jeﬀ 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, and David Zuhn have made contributions both large and small.

Andrew Cagney, Fernando Nasser, and Elena Zannoni, while working for Cygnus Solu-

tions, implemented the original gdb/mi interface.

Jim Blandy added support for preprocessor macros, while working for Red Hat.

Andrew Cagney designed gdb’s architecture vector. Many people including Andrew

Cagney, Stephane Carrez, Randolph Chung, Nick Duﬀek, Richard Henderson, Mark Ket-

tenis, Grace Sainsbury, Kei Sakamoto, Yoshinori Sato, Michael Snyder, Andreas Schwab,

Jason Thorpe, Corinna Vinschen, Ulrich Weigand, and Elena Zannoni, helped with the

migration of old architectures to this new framework.

Andrew Cagney completely re-designed and re-implemented gdb’s unwinder framework,

this consisting of a fresh new design featuring frame IDs, independent frame sniﬀers, and

the sentinel frame. Mark Kettenis implemented the dwarf 2 unwinder, Jeﬀ Johnston the

libunwind unwinder, and Andrew Cagney the dummy, sentinel, tramp, and trad unwinders.

The architecture-speciﬁc changes, each involving a complete rewrite of the architecture’s

frame code, were carried out by Jim Blandy, Joel Brobecker, Kevin Buettner, Andrew

Cagney, Stephane Carrez, Randolph Chung, Orjan Friberg, Richard Henderson, Daniel

Jacobowitz, Jeﬀ Johnston, Mark Kettenis, Theodore A. Roth, Kei Sakamoto, Yoshinori

Sato, Michael Snyder, Corinna Vinschen, and Ulrich Weigand.

Christian Zankel, Ross Morley, Bob Wilson, and Maxim Grigoriev from Tensilica, Inc.

contributed support for Xtensa processors. Others who have worked on the Xtensa port of

gdb in the past include Steve Tjiang, John Newlin, and Scott Foehner.

Michael Eager and staﬀ of Xilinx, Inc., contributed support for the Xilinx MicroBlaze

architecture.

剩余586页未读，继续阅读

dll506

粉丝: 11

GDB调试指南：深入探索程序错误

GDB调试指南：Debugging with gdb

GDB调试指南：Debugging with gdb详解

GDB调试指南：Debugging with Gdb电子书精华

debuging-with-gdb.rar_GDB 中文_debuging with GDB_gdb

gdb.rar_debuging with GDB_gdb

Debugging-with-GDB.zip_Debugging with GDB

Debugging with gdb

Debugging with GDB

debugging with gdb

debugging with GDB

最新资源