Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

GDB

News GCC Best C books Recommended Links Debugging Make
Richard Stallman and War of Software Clones The Short History of GCC development Classic Unix tools History Humor Etc

Edited content from Wikipedia

GDB was first written by Richard Stallman in 1986 as part of his GNU project. It was the third major program after Emacs and GCC created in the project. It was modeled after the DBX debugger from BSD. Like with other major GNU programs Stallman soon lost control of the development and from 1990 to 1993 it was maintained by John Gilmore while he worked for Cygnus Solutions. Now it is maintained by the GDB Steering Committee which is appointed by the Free Software Foundation. (See GDB- The GNU Project Debugger). GDB is still actively developed and available on all major architectures.  Among good tutorials:

GDB Cheat Sheet is available from yolinux project. See also O'Reilly Linux Command Directory gdb

GDB offers standard facilities the allow tracing and altering the execution of computer programs. The user can monitor and modify the values of programs' internal variables, and call functions independently of the program's normal behavior. Since version 7.0, support for "reversible debugging" — allowing a debugging session to step backward, much like rewinding a crashed program to see what happened — is available.  Version 7.0 new features also include support for Python scripting.

GDB offers a 'remote' mode often used when debugging embedded systems. Remote operation is when GDB runs on one machine and the program being debugged runs on another. GDB can communicate to the remote 'stub' which understands GDB protocol via serial connection or TCP/IP.[9] A stub program can be created by linking to the appropriate stub files provided with GDB, which implement the target side of the communication protocol.[10] Alternatively, gdbserver can be used to remotely debug the program without needing to change it in any way. The same mode is also used by KGDB for debugging a running Linux kernel on the source level with gdb. With KGDB, kernel developers can debug a kernel in much the same way as they debug application programs. It makes it possible to place breakpoints in kernel code, step through the code and observe variables. On architectures where hardware debugging registers are available, watchpoints can be set which trigger breakpoints when specified memory addresses are executed or accessed. KGDB requires an additional machine which is connected to the machine to be debugged using a serial cable or ethernet. On FreeBSD, it is also possible to debug using Firewire direct memory access(DMA).

The debugger does not contain its own graphical user interface, and defaults to a command-line interface. Several front-ends have been built for it, such as Xxgdb, Data Display Debugger (DDD), Nemiver, KDbg, Xcode debugger, GDBtk/Insight and the HP Wildebeest Debugger GUI (WDB GUI). IDEs such as Codelite, Code::Blocks, Dev-C++, GNAT Programming Studio (GPS), KDevelop, Qt Creator, MonoDevelop, Eclipse, NetBeans and VisualStudio (see VS AddIn Gallery) can interface with GDB. GNU Emacs has a "GUD mode" and several tools for VIM exist[citation needed]. These offer facilities similar to debuggers found in IDEs.

Some other debugging tools have been designed to work with GDB, such as memory leak detectors.

An example session

Command run -v run the loaded program with the parameters bt backtrace (in case the program crashed) info registers dump all registers disass $pc-32, $pc+32 disassemble

Consider the following source-code written in C:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
size_t
foo_len (const char *s)
{
  return strlen (s);
}
 
int
main (int argc, char *argv[])
{
  const char *a = NULL;
 
  printf ("size of a = %d\n", foo_len (a));
 
  exit (0);
}

Using the GCC compiler on GNU/Linux, the code must be compiled using the -g flag in order to include appropriate debug information on the binary generated, thus making it possible to inspect it using GDB. Assuming that the file containing the code above is named example.c, the command for the compilation could be:

gcc example.c -g -o example 

And the binary can now be run:

# ./example
Segmentation fault 

Since the example code, when executed, generates a segmentation fault, GDB can be used to inspect the problem.

# gdb ./example
GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /path/example...done.
(gdb) run
Starting program: /path/example 

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400527 in foo_len (s=0x0) at example.c:8
8         return strlen (s);
(gdb) print s
$1 = 0x0

Program received signal SIGSEGV, Segmentation fault. 0x0000000000400527 in foo_len (s=0x0) at example.c:8 8 return strlen (s); (gdb) print s $1 = 0x0 The problem is present in line 8, and occurs when calling the function strlen (because its argument, s, is NULL).

Depending on the implementation of strlen (in-line or not), the output can be different.

To fix the problem, the variable a (in the function main) must contain a valid string. Here is a fixed version of the code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
size_t
foo_len (const char *s)
{
  return strlen (s);
}
 
int
main (int argc, char *argv[])
{
  const char *a = "This is a test string";
 
  printf ("size of a = %d\n", foo_len (a));
 
  exit (0);
}
Recompiling and running the executable again inside GDB now gives a correct result:
GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /path/example...done.
(gdb) run
Starting program: /path/example 
size of a = 21
[Inferior 1 (process 14290) exited normally]

GDB prints the output of printf in the screen, and then informs the user that the program exited normally.
Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Oct 10, 2007] GNU Project Debugger More fun with GDB by Bill Zimmerly

Oct 03, 2006
GDB, the GNU Project Debugger, has a macro capability that is sophisticated and allows you to personalize and customize GDB to have just the tools you need. The mechanism for providing help documentation on your customized commands makes it an easy tool to share with others as well.

The previous article on this topic, "Fun with strace and GDB," covered the basics of using these tools to explore your system and attach to programs that are already running to see what they were doing. This article presses on to customize the debugger to make the experience more personal and efficient.

When GDB, the GNU Project Debugger, starts up, it looks for a file in the current user's home directory called .gdbinit; if the file exists, GDB executes all the commands in the file. Normally, this file is used for simple configuration commands, such as setting the default assembler format desired (Intel® or Motorola) or default radix to display input and output data (decimal or hexadecimal). It can also read a macro-coding language that allows m

GDB was first written by Richard Stallman in 1986 as part of his GNU system, after his GNU Emacs was "reasonably stable".[3] GDB is free software released under the GNU General Public License (GPL). It was modeled after the DBX debugger, which came with Berkeley Unix distributions.[3]

From 1990 to 1993 it was maintained by John Gilmore while he worked for Cygnus Solutions[citation needed]. Now it is maintained by the GDB Steering Committee which is appointed by the Free Software Foundation.[4]

[edit] Release history2012 August 17: GDB 7.5 2012 April 26: GDB 7.4.1 2012 January 24: GDB 7.4 2011 July 26: GDB 7.3[5] 2010 September 2: GDB 7.2 2010 March 18: GDB 7.1 2009 October 6: GDB 7.0 2008 March 27: GDB 6.8 2003 October 3: GDB 6.0 [edit] Technical details[edit] FeaturesGDB offers extensive facilities for tracing and altering the execution of computer programs. The user can monitor and modify the values of programs' internal variables, and even call functions independently of the program's normal behavior.

GDB target processors (as of 2003) include: Alpha, ARM, AVR, H8/300, System/370, System 390, X86 and its 64-bit extension X86-64, IA-64 "Itanium", Motorola 68000, MIPS, PA-RISC, PowerPC, SuperH, SPARC, and VAX. Lesser-known target processors supported in the standard release have included A29K, ARC, ETRAX CRIS, D10V, D30V, FR-30, FR-V, Intel i960, 68HC11, Motorola 88000, MCORE, MN10200, MN10300, NS32K, Stormy16, and Z8000. (Newer releases will likely not support some of these.) GDB has compiled-in simulators for even lesser-known target processors such like M32R or V850.[6]

GDB is still actively developed. As of version 7.0 new features include support for Python scripting.[7] Since version 7.0, support for "reversible debugging" — allowing a debugging session to step backward, much like rewinding a crashed program to see what happened — is available.[8]

[edit] Remote debuggingGDB offers a 'remote' mode often used when debugging embedded systems. Remote operation is when GDB runs on one machine and the program being debugged runs on another. GDB can communicate to the remote 'stub' which understands GDB protocol via Serial or TCP/IP.[9] A stub program can be created by linking to the appropriate stub files provided with GDB, which implement the target side of the communication protocol.[10] Alternatively, gdbserver can be used to remotely debug the program without needing to change it in any way.

The same mode is also used by KGDB for debugging a running Linux kernel on the source level with gdb. With KGDB, kernel developers can debug a kernel in much the same way as they debug application programs. It makes it possible to place breakpoints in kernel code, step through the code and observe variables. On architectures where hardware debugging registers are available, watchpoints can be set which trigger breakpoints when specified memory addresses are executed or accessed. KGDB requires an additional machine which is connected to the machine to be debugged using a serial cable or ethernet. On FreeBSD, it is also possible to debug using Firewire direct memory access (DMA)[citation needed].

[edit] Graphical user interfaceThe debugger does not contain its own graphical user interface, and defaults to a command-line interface. Several front-ends have been built for it, such as Xxgdb, Data Display Debugger (DDD), Nemiver, KDbg, Xcode debugger, GDBtk/Insight and the HP Wildebeest Debugger GUI (WDB GUI). IDEs such as Codelite, Code::Blocks, Dev-C++, GNAT Programming Studio (GPS), KDevelop, Qt Creator, MonoDevelop, Eclipse, NetBeans and VisualStudio (see VS AddIn Gallery) can interface with GDB. GNU Emacs has a "GUD mode" and several tools for VIM exist[citation needed]. These offer facilities similar to debuggers found in IDEs.

Some other debugging tools have been designed to work with GDB, such as memory leak detectors.

[edit] Examples of commandsgdb program debug "program" (from the shell) run -v run the loaded program with the parameters bt backtrace (in case the program crashed) info registers dump all registers disass $pc-32, $pc+32 disassemble

[edit] An example sessionConsider the following source-code written in C:

#include <stdio.h> #include <stdlib.h> #include <string.h>

size_t foo_len (const char *s) { return strlen (s); }

int main (int argc, char *argv[]) { const char *a = NULL;

printf ("size of a = %d\n", foo_len (a));

exit (0); } Using the GCC compiler on GNU/Linux, the code above must be compiled using the -g flag in order to include appropriate debug information on the binary generated, thus making it possible to inspect it using GDB. Assuming that the file containing the code above is named example.c, the command for the compilation could be:

gcc example.c -g -o example And the binary can now be run:

# ./example Segmentation fault Since the example code, when executed, generates a segmentation fault, GDB can be used to inspect the problem.

# gdb ./example GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /path/example...done. (gdb) run Starting program: /path/example

Program received signal SIGSEGV, Segmentation fault. 0x0000000000400527 in foo_len (s=0x0) at example.c:8 8 return strlen (s); (gdb) print s $1 = 0x0 The problem is present in line 8, and occurs when calling the function strlen (because its argument, s, is NULL).

Depending on the implementation of strlen (in-line or not), the output can be different, e.g.:

# gdb ./example GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/gdb/example...done.

(gdb) run Starting program: /tmp/gdb/example

Program received signal SIGSEGV, Segmentation fault. 0xb7ee94f3 in strlen () from /lib/i686/cmov/libc.so.6

(gdb) bt #0 0xb7ee94f3 in strlen () from /lib/i686/cmov/libc.so.6 #1 0x08048435 in foo_len (s=0x0) at example.c:8 #2 0x0804845a in main (argc=<optimized out>, argv=<optimized out>) at example.c:16 To fix the problem, the variable a (in the function main) must contain a valid string. Here is a fixed version of the code:

#include <stdio.h> #include <stdlib.h> #include <string.h>

size_t foo_len (const char *s) { return strlen (s); }

int main (int argc, char *argv[]) { const char *a = "This is a test string";

printf ("size of a = %d\n", foo_len (a));

exit (0); } Recompiling and running the executable again inside GDB now gives a correct result:

GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /path/example...done. (gdb) run Starting program: /path/example size of a = 21 [Inferior 1 (process 14290) exited normally] GDB prints the output of printf in the screen, and then informs the user that the program exited normally.

[edit] See also Free software portal Computer programming portal Affinic Debugger GUI Binary File Descriptor library (libbfd) dbx ddd, a GUI for gdb and other debuggers gdbserver [edit] References1.^ "GDB Documentation - Supported Languages". http://sourceware.org/gdb/current/onlinedocs/gdb/Supported-Languages.html#Supported-Languages. Retrieved 2011-11-28. 2.^ "GDB Documentation - Summary". http://sourceware.org/gdb/current/onlinedocs/gdb/Summary.html#Summary. Retrieved 2011-11-28. 3.^ a b "Richard Stallman lecture at the Royal Institute of Technology, Sweden (1986-10-30)". http://www.gnu.org/philosophy/stallman-kth.html. Retrieved 2006-09-21. "Then after GNU Emacs was reasonably stable, which took all in all about a year and a half, I started getting back to other parts of the system. I developed a debugger which I called GDB which is a symbolic debugger for C code, which recently entered distribution. Now this debugger is to a large extent in the spirit of DBX, which is a debugger that comes with Berkeley Unix." 4.^ "GDB Steering Committee". http://www.gnu.org/software/gdb/committee/. Retrieved 2008-05-11. 5.^ http://www.gnu.org/software/gdb/news/ 6.^ "GDB Documentation - Summary - Contributors". http://sourceware.org/gdb/current/onlinedocs/gdb/Contributors.html#Contributors. Retrieved 2011-12-01. 7.^ "GDB 7.0 Release Notes". http://sourceware.org/gdb/wiki/GDB_7.0_Release. Retrieved 2011-11-28. 8.^ "Reverse Debugging with GDB". http://www.sourceware.org/gdb/wiki/ReverseDebug. Retrieved 2012-6-28. 9.^ Howto: GDB Remote Serial Protocol: Writing a RSP Server 10.^ Implementing a remote stub [edit] External linksOfficial website KGDB: Linux Kernel Source Level Debugger MyGDB: GDB Frontend web site which is In Korean language A Visual Studio plugin for debugging with GDB [edit] DocumentationRichard M. Stallman, Roland Pesch, Stan Shebs, et al., Debugging with GDB (Free Software Foundation, 2011) ISBN 978-0-9831592-3-0 GDB Internals [edit] TutorialsPeter Jay Salzman's GDB guide: Using The GNU GDB Debugger (Peter Jay Salzman) RMS's gdb Tutorial (Ryan Schmidt

ore powerful customizations. The language follows this basic format:

define <command>
<code>
end
document <command>
<help text>
end

The command is known as a user command. All other standard GDB commands can be combined with flow-control instructions and passed parameters to create a language that allows you to customize the behavior of the debugger for the specific application being debugged.

Start simple: Clear the screen

It's always good to start simple and build up from there. Start the xterm, fire up your favorite editor, and let's begin creating a useful .gdbinit file! The output from debuggers can be messy and, as a matter of personal preference, many people like to be able to clear the screen when working with any tool that has the potential for creating cluttering. GDB has no built-in command for clearing the screen, but it can call shell functions; the following code steps outside the debugger to clear the xterm console with the cls command:

define cls
shell clear
end
document cls
Clears the screen with a simple command.
end

The upper portion of the definition, bounded by the define ... end verbs, frames the code that is executed when the command is invoked.

The lower portion of the definition, bounded by document ... end, is used by the GDB command interpreter to display help text associated with the cls command when you type help cls.

After you type the code into the .gdbinit file, fire up GDB and enter the cls command. Your screen clears, and all you see is the GDB prompt. Your journey into GDB customization has begun!

The importance of documentation

If you enter the help user command, you see a summary of all the user commands you've entered in the .gdbinit file. The designers of the .gdbinit user-defined commands have provided an important feature that you shouldn't ignore when you're writing your own commands: the document ... end clause. Maintaining functional documentation of how commands work becomes critical as the number of these commands increase.

You might have already experienced the problem. Suppose you wrote some code from a few years ago; then, when you revisit it, perhaps to fix a bug or modify it by adding a new feature, you realize that you're having a hard time understanding your own code. Good programmers make it a habit to keep code short, simple, and well-documented so that it's maintainable.

What's true for programming code in general is true for debugger code. Keeping careful notes and well-documented code will serve you well as you work your way through this most rewarding of careers.

Community uses for GDB

Human beings learn new things many ways, including by studying what others have done. Budding automotive engineers start by opening the hood of their first car, pulling out their tools, and removing parts to clean and study. Such an exercise lets them keep a clean machine while learning how the automobile engine works.

Budding computer scientists are no different in that they want to see just how programs work -- how they interact with dynamic libraries and the native operating system. The tool for seeing how these things work is the debugger. Computer programming is a complex activity, and by being able to interact with a community of like-minded people, asking questions and getting answers, new computer scientists can satisfy their need for knowledge.

In the global programming community, there are always a healthy number of people who hunger and thirst for knowledge. They aren't content with just running programs on their computers -- they want to know more. They want to know how those programs run, and they enjoy exploring the functionality of their systems with the best tool available for the purpose: the debugger. By reverse engineering, a way of learning how programs work by running them under a debugger and keeping careful notes of how they do what they do, you can learn a lot from what the authors of the program being studied have done. Many low-level details involved in programming are undocumented; the only way to learn about them is to see them in action.

Reverse engineering has an undeserved reputation as a black art practiced only by hackers and criminals intent on breaking copy-protection systems and writing worms and viruses to inflict harm on the world of computers. Although there are such people, the vast majority of those who study how programs work, using debuggers and reverse engineering, are the present and future software engineers who want and need to know how these things work. They have formed online communities to share their knowledge and discoveries; discouraging this activity is destructive and retards the future progress of computer science.

Many of the user functions defined in this article come from such communities of hungry knowledge seekers. If you want to know more about them, you're encouraged to study the Web sites referenced in the Resources section of this document.

Breakpoint aliases

It's a well-known fact that many of the GDB commands are too verbose. Even though they can be abbreviated, the GDB macro language allows for even greater simplifications. Commands, such as info breakpoints, can be made as simple as bpl. Listing 1 shows a great set of such simple and highly useful breakpoint alias user commands to edit into your growing .gdbinit file.

Listing 1: Breakpoint alias commands
define bpl
info breakpoints
end
document bpl
List breakpoints
end

define bp
set $SHOW_CONTEXT = 1
break * $arg0
end
document bp
Set a breakpoint on address
Usage: bp addr
end

define bpc
clear $arg0
end
document bpc
Clear breakpoint at function/address
Usage: bpc addr
end

define bpe
enable $arg0
end
document bpe
Enable breakpoint #
Usage: bpe num
end

define bpd
disable $arg0
end
document bpd
Disable breakpoint #
Usage: bpd num
end

define bpt
set $SHOW_CONTEXT = 1
tbreak $arg0
end
document bpt
Set a temporary breakpoint on address
Usage: bpt addr
end

define bpm
set $SHOW_CONTEXT = 1
awatch $arg0
end
document bpm
Set a read/write breakpoint on address
Usage: bpm addr
end

Once you get used to using breakpoint alias commands, your debugging sessions become more rewarding; these commands greatly increase the debugger's effectiveness, because you can accomplish more with less effort.

Displaying process information

The GDB user-defined commands can be called by other user-defined commands, leading to greater effectiveness for them all. This is the incremental nature of programming languages -- writing lower-level functions that are called by progressively higher-level functions until the tools conveniently do what you want them to do with minimal effort on your part. The next set of GDB definitions to incorporate into your .gdbinit file display useful process information when they're invoked, as shown in Listing 2 .

Listing 2: Process information commands
define argv
show args
end
document argv
Print program arguments
end

define stack
info stack
end
document stack
Print call stack
end

define frame
info frame
info args
info locals
end
document

[Jun 28, 1999] Guide to Debugging (gdb)

[Jul 18, 1999] Norman Matloff's Debugging Tutorial

Why waste huge amounts of time debugging? Do yourself a favor and learn to debug like a professional. In this Web page Prof. Norman Matloff has some resources which hopefully will be useful to you in that regard.

First, there is Norm Matloff's introduction to the art of debugging and gdb. The first part of that document lays out a general strategy for debugging, and then illustrates the strategy using the gdb debugging tool.

The other resource available here is information by Dr. Matloff on ddd, a graphical front end to gdb. Note that ddd is available on CSIF machines in the directory /altpkg/ddd, and on Linux sites in the directory devel/debuggers/ddd.

Here is documentation on ddd:

[Jun 28, 1999] GDB Tutorial

A shorter, more command explanatory gdb tutorial than the one above

ltrace is a library call tracer, i.e. a debugging tool which prints out a trace of all the dynamic library calls made by another process/program. It also displays system calls, as well as `strace'. The program to be traced need not be recompiled for this, so you can use it on binaries for which you don't have the source handy.

Version 0.3.6 adds support for Linux/ARM and Linux/m68k machines.

kdbg 0.2.3

KDbg is a graphical user interface to gdb, the GNU debugger. It provides an intuitive interface for setting breakpoints, inspecting variables, and stepping through code.

DDD 3.0.91

The Data Display Debugger (DDD) is a common graphical user interface for GDB, DBX, and XDB, the popular UNIX debuggers. Besides ``classical'' front-end features such as viewing source texts, DDD provides a graphical data display, where data structures are displayed as graphs. A simple mouse click dereferences pointers or views structure contents, updated each time the program stops. Using DDD, you can reason about your application by viewing its data, not just by viewing it execute lines of source code.

This is the second beta version for 3.1. It fixes all the bugs reported for the first one (3.0.90).

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Guide to Debugging (gdb)

GDB Tutorial - a shorter, more command explanatory gdb tutorial than the one above !!!NEW!!!

GDB Internals - Table of Contents

GDB The GNU Debugger -- main page from cygnos

GDB FTP directory -- from cygnus -- the lkatest version is there

Debugging with GDB - Table of Contents

Debugging with GDU - Table of Contents

Online Manuals

Doug Rohde  ``An introduction to using gdb under Emacs''

GNU Emacs Manual - Debugger Operation

KgdbSparc

Using the VxGDB GNU Debugger

Tutorials

Wikipedia references

  1. ^ "GDB Documentation - Supported Languages". http://sourceware.org/gdb/current/onlinedocs/gdb/Supported-Languages.html#Supported-Languages. Retrieved 2011-11-28. 
  2. ^ "GDB Documentation - Summary". http://sourceware.org/gdb/current/onlinedocs/gdb/Summary.html#Summary. Retrieved 2011-11-28. 
  3. ^ a b "Richard Stallman lecture at the Royal Institute of Technology, Sweden (1986-10-30)". http://www.gnu.org/philosophy/stallman-kth.html. Retrieved 2006-09-21. "Then after GNU Emacs was reasonably stable, which took all in all about a year and a half, I started getting back to other parts of the system. I developed a debugger which I called GDB which is a symbolic debugger for C code, which recently entered distribution. Now this debugger is to a large extent in the spirit of DBX, which is a debugger that comes with Berkeley Unix." 
  4. ^ "GDB Steering Committee". http://www.gnu.org/software/gdb/committee/. Retrieved 2008-05-11. 
  5. ^ http://www.gnu.org/software/gdb/news/
  6. ^ "GDB Documentation - Summary - Contributors". http://sourceware.org/gdb/current/onlinedocs/gdb/Contributors.html#Contributors. Retrieved 2011-12-01. 
  7. ^ "GDB 7.0 Release Notes". http://sourceware.org/gdb/wiki/GDB_7.0_Release. Retrieved 2011-11-28. 
  8. ^ "Reverse Debugging with GDB". http://www.sourceware.org/gdb/wiki/ReverseDebug. Retrieved 2012-6-28. 
  9. ^ Howto: GDB Remote Serial Protocol: Writing a RSP Server
  10. ^ Implementing a remote stub

 



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: October, 27, 2015