Literatur zum Thema "Debugging"

Da jeder Debugger etwas anders bedient wird, solltest du auf jeden Fall
das mitgelieferte Handbuch lesen. Da die Verwendung eines Debuggers
keiner hohe Theorie bedarf, glaube ich nicht, dass du noch zusätzliche
Allgemeinliteratur brauchst.

Ich muss zugeben, dass ich noch nicht einmal die Anleitungen der von mir
verwendeten Debugger vollständig gelesen habe. Ausprobieren und die
meist sehr knapp gehaltene Online-Hilfe haben gereicht.

Hi,

du musst nur mal nen Debugger starten, dann siehst du recht schnell, wie 
der funktioniert.

Ich hab für µVision oder Visual Studio auch noch nie ein Handbuch 
gelesen :-)

Im Grunde heisst debuggen:
- Breakpoints setzen (Address oder Data)
- Steppen (in, out, over function)
- Variablen (bei embedded noch Register) -werte ansehen und verändern
- Speicherbereiche und Strukturen ansehen, ggf. Werte ändern

Dazu kommen dann noch Spezialitäten, die der Debugger so unterstützt. 
Aber das ist das grundlegende Handwerkszeug, was ca. 90% der Debug-Zeit 
benötigt wird.


Das schöne z.B. am Visual Studio ist, dass du nach einem erreichten BP 
den Code ändern kannst (lokale Änderungen in der Funktion), und dann 
wird bei Go oder Step der Code neu compiliert und du kannst 
weiterdebuggen, ohne die laufende Session beendet zu haben.


VG,
/th.

Hallo'!

Random ... schrieb:
> Dazu kommen dann noch Spezialitäten, die der Debugger so unterstützt.

Gerade die Spezialitäten können Dir das Leben doch deutlich 
vereinfachen. Mal für das Visual Studio gesprochen: Das Wissen um 
Pseudoregister und das Formatieren des Outputs brauche ich in allen 
meinen Projekten. Z.B. habe ich die beiden Einträge

@EAX,hr
@ERR,hr

in nahezu allen Projekten im Watchwindow stehen. Und das Breakpoints 
deutlich mehr als der schlichte Druck auf F9 sein können, hat mir auch 
schon oft geholfen. Und so ganz uninteressant ist die autoexp.dat nun 
auch nicht, nur kennt die kaum einer.

Falls hier also tatsächlich ein Visual Studio im Spiel sein sollte, kann 
ich "Debugging Applications" von John Robbins empfehlen. Die Auflage von 
2000 ist zwar nicht die Neueste, hat aber nur wenig an Aktualität 
verloren und gibt es bei Amazon auch in gebraucht.

Und ja, ich habe tatsächlich ein Buch übers Debuggen gelesen. :-)

Hallo zusammen,
danke für die Antworten. Ich habe meine Frage bewußt allgemein gehalten, 
um allgemeine Antworten zu bekommen.

Das liegt daran, daß ich es momentan für an der Zeit halte, mal wieder 
die Programmiersprache für den PC zu wechseln - und noch nicht weiß, 
welche es werden soll. Deswegen wollte ich die Wahl auch von den 
Debug-Möglichkeiten abhängig machen- wenn ich denn wüßte, worauf man 
achten sollte. Breakpoints und Step-In scheinen allgemein verbreitet zu 
sein - aber ist das alles?

Deswegen halte ich es für angebracht, mich über Debugging (von Software 
- das fabelhafte Buch "Debugging" von David J. Agans kenne ich -) schlau 
zu machen.

Deutsch oder Englisch ist nachrangig- ersteres geht am späteren Abend 
etwas zügiger zu lesen, bei letzterem kennt man die Begriffe dafür meist 
schon besser, weil man sie in unzähligen Hilfetexten und Dokus schon 
gesehen hat.

Viele Grüße
Nicolas

Nicolas S. schrieb:
> danke für die Antworten. Ich habe meine Frage bewußt allgemein gehalten,
> um allgemeine Antworten zu bekommen.
>
> Das liegt daran, daß ich es momentan für an der Zeit halte, mal wieder
> die Programmiersprache für den PC zu wechseln - und noch nicht weiß,
> welche es werden soll.

Wenn du noch nicht einmal weißt, welche Programmiersprache du verwenden
willst, ist deine Anfrage allerdings sehr allgemein :)

Geh mal davon aus, dass das Debugging in C, Prolog und Haskell (nur um
ein paar Beispiele zu nennen) dreimal völlig unterschiedlich abläuft.
Single-Step und dergleichen wirst du bei den letzten beiden (zumindest
in der üblichen Form) vergeblich suchen.

ein buch, was ich sehr nett fand:
http://www.amazon.com/Debugging-David-J-Agans/dp/0814474578

Es vermittelt anhand von interasssanten und amüsanten Annekdoten was man 
allgemein beim Debuggen von Systemen beachten sollte.