In diesem kurzen Tutorial möchte ich ein Tool vorstellen, das für viele Programmierer dieser Welt essentiell geworden ist, es ist der GNU Debugger, oder auch kurz GDB.
Er ist in den Reihen der ersten Programme, die für das GNU¹⁾-Betriebssystem (ein freier Klon von Unix) entstanden sind.

Richtig angewendet kann er eine große Hilfe zum aufspüren jeglicher Art von Programmierfehlern sein und viel Zeit ersparen.

GDB ist ein sogenannter „Debugger“, das ist ein Werkzeug, das dem Programmierer hilft Fehler in einem Programm zu finden. Er tut das, indem er euch Einblick in einen Prozess gewährt, ein Objekt das normalerweise für einen Menschen undurchsichtig und verschlossen ist (quasi eine „black box“).
Ihr könnt in dem Prozess bestimmte Dinge beobachten, dazu zählen:

• Maschinencode
• Speicher
• Prozessorregister
• Signale
• Threads

Da in einem Prozess meist sehr viele Dinge in Bruchteilen von Sekunden ablaufen, und so Beobachtungen sehr schwierig werden, gibt es mehrere Möglichkeiten euren Prozess dort anzuhalten wo ihr das braucht:

• An selbst festgelegten Haltepunkten
• An selbst festgelegten Haltepunkten wenn eine bestimmte Bedingung zutrifft
• Wenn sich ein Ausdruck ändert („Watch Expression“)
• Wenn ein bestimmtes Signal gesendet wird
• Wenn das Programm „abschmiert“

Außerdem könnt ihr mit einem Debugger auch schreibend auf den Prozess zugreifen, also indem ihr Prozessorregister, Speicherbereiche oder Variablen setzt.

Hat man den Quellcode zur Verfügung, kann man in kürzester Zeit Fehler im Programm finden und zurückverfolgen.

Hat man den Quellcode nicht zur Verfügung liefert das Werkzeug eine Möglichkeit, von der fertigen ausführbaren Datei (und eigentlich dem Prozess) auf die Funktion und die Funktionsweise des Programms zu schließen. Das nennt man „reverse engineering“.

Der GNU Debugger funktioniert mit jeglicher Art von Programmen in Maschinencode ²⁾, und es gibt Unterstützung für viele Programmiersprachen, darunter C, C++, Fortran, Ada und so weiter. Was ich mit „Unterstützung für eine Programmiersprache“ meine, darauf werde ich später noch zurückkommen.

GDB ist kein Ersatz für das Gehirn eines Programmierers. Obwohl ein Debugger eine große Hilfe sein kann, möchte ich davor warnen Alles und jedes Programmierproblem mit einem Debugger zu lösen. Oft sind die Betrachtung des Quellcodes oder etwaige Compilerwarnungen zielführender, und vielleicht sogar pädagogisch wertvoller.

Jemand der sich mit seinem Code intensiv auseinandersetzt, der lernt auf jeden Fall mehr als jemand, der nur schnell den Debugger zur Hand genommen hat . Denn denkt mal nach: alle Information zum Fehler steckt bereits im Quellcode!

An dieser Stelle möchte ich Linus Torvalds Zitieren, der bekanntlich kein Fan von Debuggern ist. Das Zitat stammt aus einem E-Mail aus dem Jahr 2000, das gegen einen Kernel Debugger argumentiert: http://lwn.net/2000/0914/a/lt-debugger.php3:

I happen to believe that not having a kernel debugger forces people to
think about their problem on a different level than with a debugger. I
think that without a debugger, you don't get into that mindset where you
know how it behaves, and then you fix it from there. Without a debugger,
you tend to think about problems another way. You want to understand
things on a different _level_.

Eine kleine Anmerkung: im Jahre 2008 wurde der KDB (Kernel Debugger) übrigens doch in den Kernel integriert.

Letztendlich bleibt es jedem Entwickler überlassen, ob er einen Debugger verwendet oder nicht. Wenn ihr euch dafür entscheidet, verwendet ihn bitte mit Hirn!

• GDB Befehlsreferenz
• Starten und Befehle eingeben
• Hilfe