GDB调试指南：Linux程序调试必备

5星 · 超过95%的资源需积分: 9 147 浏览量更新于2024-07-28 收藏 1.96MB PDF 举报

"调试工具GDB的使用指南，适用于在Linux环境下进行程序开发的程序员，由Richard Stallman等人编写，并由Free Software Foundation出版。" 在编程领域，调试是软件开发过程中不可或缺的一环，GDB（GNU Source-Level Debugger）是Linux环境下的一个强大调试工具。这篇文档《Debugging with gdb》提供了关于GDB的详细使用手册，适用于GDB版本7.4.50.20120417。文档由Richard Stallman、Roland Pesch、Stan Shebs等多位作者共同撰写，旨在帮助开发者更有效地定位和解决代码中的问题。 GDB的基本功能包括： 1. **设置断点**：允许你在程序执行到特定位置时暂停，以便检查此时的变量值、内存状态或者调用堆栈。 2. **单步执行**：可以逐行执行代码，查看每一步的变化，这对于理解程序流程非常有帮助。 3. **查看和修改变量**：在运行时查看和修改变量的值，以测试不同的假设和场景。 4. **调用堆栈管理**：查看和操作调用堆栈，了解函数调用的层次关系。 5. **内存检查**：检查和修改内存内容，找出内存泄漏或越界等问题。 6. **异常处理**：捕获和处理运行时错误，如除以零、空指针引用等。 7. **远程调试**：支持对运行在其他系统或设备上的程序进行调试。 8. **多线程和多进程调试**：GDB能够处理多线程和多进程程序，让你能跟踪每一个线程或进程的状态。 9. **脚本支持**：通过GDB的命令脚本功能，可以自动化一些重复的调试任务。 10. **符号表解析**：GDB可以读取程序的符号表信息，提供函数名、变量名等有意义的调试信息。 11. **动态加载库支持**：即使程序使用了动态链接的库，GDB也能正确地调试。 12. **源码级别的调试**：GDB能够与源代码结合，使调试更加直观。通过学习这份文档，你可以掌握如何启动GDB、加载你的程序、设置调试选项、启动调试会话以及如何有效利用GDB提供的各种命令来解决问题。它还涵盖了如何报告GDB的bug以及获取GDB社区的支持。购买GDB的官方出版物，不仅能支持Free Software Foundation在发展GNU项目和推广自由软件上的工作，还能获得一份实体版的手册，方便随时查阅。《Debugging with gdb》是每一位Linux程序员的必备参考书，无论你是初学者还是经验丰富的开发者，都能从中受益，提高调试效率，从而更好地理解和优化你的代码。

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 169. For more information, see Section 15.4.1 [C

and C++], page 169.

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

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

[Modula-2], page 178.

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

[OpenCL C], page 177.

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.

剩余621页未读，继续阅读

dujiachen

粉丝: 0
资源: 5

GDB调试指南：Linux程序调试必备

gdb手册debuging with gdb 中文

debuging with gdb 中文

debuging with gdb英文版

debuging with GDB

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

gdb.rar_debuging with GDB_gdb

gdb手册debuging with gdb 中文 .zip

gdb中文手册(debuging with gdb) 140页

gdb手册(debuging with gdb)(中文)-wrapper

gdb手册(debuging with gdb)(中文) (shyboysby.spaces.live.com 译) (z-li

最新资源