Diskussion:Debugsymbol

Quellsprachenebene

Um auf "Quellsprachenebene" debuggen zu können, sind Symbol-Informationen nicht notwendig (wenn auch sehr hilfreich...) --arilou 15:38, 11. Apr. 2011 (CEST)

Debugsymbole und Optimierung

Ich halte den Satz "Meist unterlässt der Compiler daraufhin umfangreichere Optimierungen" für unpassend. Erstens ist dies bei mindestens einem sehr verbreiteten Compiler (GCC) nicht der Fall und technisch auch überhaupt nicht notwendig, zweitens ist die Angabe "meistens" ohne jede Quellenangabe oder Vergleichspunkt äußerst unglücklich. Ich würde den Satz weglassen. (nicht signierter Beitrag von 134.93.136.193 (Diskussion) 19:35, 13. Jul 2012 (CEST))

Ich kann mich dem Vorredner nur anschliessen. Auch beim C++-Compiler von Microsoft ist das nicht der Fall. Ausserdem sind die Punkte, die bei den Nachteilen angegeben werden, auch nicht für alle Compiler zutreffend. Erzeugt man die Debugsymbols unter Windows als PDB-File, so wird das Compilat deshalb nicht viel grösser. Sofern man diese nicht mit ausliefert, kann auch kein Kunde damit dekompilieren. Nur der Hersteller kann damit Crash-Dumps auswerten. -- 193.222.66.44 10:33, 20. Jun. 2014 (CEST)

Würde mich sehr interessieren, wie man ein Unterprogramm debuggen kann, das vom Compiler mittels Inline-Ersetzung eliminiert wurde... oder eine entrollte Schleife - deren Schleifenzähler gibt's dann im Kompilat ggf. gar nicht mehr. Vmtl. geht das wohl irgendwie, aber die einfachste Variante ist, im "Debug-Fall" gar nicht zu optimieren - dann gehört zu jedem Quelltextbefehl "sein Codeabschnitt".

Aber natürlich sollten Artikelinhalte bequellt sein, oder zumindest entsprechend relativiert werden, wenn es Gegenbeispiele gibt, klar.

--arilou (Diskussion) 13:32, 23. Jun. 2014 (CEST)

Das debuggen ist eigentlich kein Problem, wenn man sich immer bewusst ist, das man es mit einer Release-Variante (also optimiertem Code) zu tun hat.

In den Debug-Infos ist ja nicht enthalten welche Programmzeile welcher Codestelle entspricht, sondern genau umgedreht. Es steht drin, welcher Binärcode zu welcher Programmzeile gehört.

Bei Inline-Funktionen und entrollten Schleifen ist das kein Problem. Da kann man im Einzelschrittmodus genau so durchsteppen. Lediglich wenn der Compiler ähnlichen Code shart, dann kann es passieren, dass man sich plötzlich in einer anderen Stelle im Quellcode wiederfindet. Wahrscheinlich gewinnt da die erste Quellcodezeile die dazu geführt hat. Das muss man vorallem beachten, wenn man Breakpoints setzen will. Normalerweise weisen einen die IDEs aber darauf hin, wenn sie keinen Binärcode zu der Codezeile haben.

Was die Variablen angeht, so kann man diese natürlich oft nicht mehr sehen. Das gilt speziell für die lokalen Variablen. Klassenvariablen und Übergabeparameter an Funktionen sind jedoch meist noch sichtbar.

Das debuggen von Release-Code soll die Entwicklung mit echten Debug-Versionen (also nicht optimiertem Code) nicht ersetzten. Es ist lediglich ein Hilfsmittel, um Fehler zu finden, die nur im Release-Build auftreten bzw. dient zum auswerten von Crash-Dumps von Kunden. -- 85.5.36.226 16:39, 24. Jun. 2014 (CEST)