Suche eine Programmiersprache!

rüdiger

Kann der VC++ Debugger auch Remote Debugging?

Aber nennt mal bitte ein Killer Feature des VC++ Debuggers, würde mich interessieren, weil der ja so hoch gelobt wurde.

@Power Off
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC27
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC28

ist vielleicht nicht sonderlich komfortabel, aber möglich

Power Off

kingruedi schrieb:

@Power Off
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC27
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC28

ist vielleicht nicht sonderlich komfortabel, aber möglich

Ja, theoretisch schon. Aber das gilt wohl nur für Betriebssysteme, die einen "ordentlichen" Kernel haben.

Bei Linux gibt es vor Kernel 2.6 das Problem, daß der Kernel z.B. im Core-Dump keine Threadinformation schreibt, weil jeder Thread ein eigener Prozess ist, und die Prozesse separat abkacken.

Bei 2.6 gibt es das Problem, daß der GDB die neuen Core-Files nicht lesen kann, oder so.

Vielleicht irre ich mich ja auch.

Ach so, ich beziehe mich natürlich auf das Post-Mortem Debugging, also nachdem das Programm abgestürzt ist.

Es gibt im Live-Betrieb noch das Problem, daß der GDB die Thread-Informationen nicht lesen kann, und daß er auf Signale seltsam reagiert.

Vielleicht habe ich schon mit SuSE 9.3 einen neuen GDB der mit dem 2.6er Kernel harmoniert. Muß ich mal ausprobieren. Hab 9.3 noch nicht so lange installiert.

Trotzdem danke!

Sovok

kingruedi schrieb:

Kann der VC++ Debugger auch Remote Debugging?

Aber nennt mal bitte ein Killer Feature des VC++ Debuggers, würde mich interessieren, weil der ja so hoch gelobt wurde.

@Power Off
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC27
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC28

ist vielleicht nicht sonderlich komfortabel, aber möglich

erstellen->remote verbindung des debuggers
der vc debugger hat viel was ich bei den gängigen anderen debuggern vermisse
in erster linie gehts da um komfort und geschwindigkeit des debuggings aber hab ich alles vorher schon genannt

Sovok

Power Off schrieb:

Sovok schrieb:

kann vc++ auch

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vchowusingeditcontinue.asp

Das ist NICHT dasselbe!

und warum ned?

Power Off

Sovok schrieb:

und warum ned?

Ganz einfach: Weil ich für Edit & Continue das Programm ändern muß, aber bei der SAS/C-Methode (bzw. GDB-Methode) nicht.

Sovok

und was heisst das jetzt? bin ich deswegen verstralt?
praktisch macht das doch garkeinen unterschied

du drückst auf pause, wechselst im callstack in deinen code, änderst die nächste zeile und gut is

Power Off

Sovok schrieb:

und was heisst das jetzt? bin ich deswegen verstralt?
praktisch macht das doch garkeinen unterschied

du drückst auf pause, wechselst im callstack in deinen code, änderst die nächste zeile und gut is

Trotzdem ... ich hätte lieber ein Command-Fenster!

Außerdem würde es mir schwer stinken, hinterher die ganzen Änderungen wieder rauszunehmen!

Talla

Power Off schrieb:

Sovok schrieb:

was meinst du mit "seinen eigenen Programmcode aufrufen"

Na z.B.
print mycoolfunc(123.4,5)
peng, Ausgabe kommt!
oder
openMyWindow( 100, 100, 200, 200 );
schwupps, ist es da!

Aus dem Debugger! Während das Programm gedebuggt wird (aber gestoppt ist).
D.h. der Debugger führt den Code aus, den ich eingebe, auch wenn er
Referenzen auf das gedebuggte Programm enthält.

Gut, 'ne? GDB kann das auch; seit ich das weiß, gefällt mir der GDB wieder viel besser.
(jetzt müßte er nur noch multithread-Programme debuggen können ...
vielleicht geht's ja jetzt mit dem 2.6er Kernel, aber früher ging's nicht)

Okay, beim klassischen C++ weiß ichs nicht genau, aber zumindest der CLR Debugger kann genau das bei C++.Net, Kannst alle Funktionen aufrufen die im Skope liegen. Funktioniert auch in C#

groovemaster schrieb:

Sehe ich nicht so. Ich finde, der Debugger beim VC++ ist ziemlich genial. Wobei ich nur gdb noch kenne, was im Vergleich dazu aber einfach nicht mithalten kann. Zumindest hab ich noch kein vernünftiges Frontend dafür gesehen. Nenn mir doch mal ein paar aussergewöhnliche Debugger, die den MS Debugger zur "Standardware" verkommen lassen.

Also ich bin durchaus selber ein Fan vom VisualStudio-Debugger, und finde nicht wirklich das er Standardware ist. Aber trotzdem gibt es schon noch einiges zu verbessern. Vor allem beim Thread-Support ist noch reichlich Luft, wenn man ihn mit dem (für Unix/Linux erhältlichen) Totalview von Etnus vergleicht. Ich gebe zu, in Sachen GUI-Entwicklung gibt es IMHO (wie bei vielen kommerziellen Unix-Anwendungen) für Etnus noch vieles zu lernen, aber die Thread-Unterstützung ist klasse. Threads können z.B. gruppiert werden und je nach Wunsch kann man mehrere Threads dann z.B. auch gemeinsam steppen lassen. Das ist eine großartige Hilfe, um Race-Conditions zu jagen.

Generell wünsche ich mir von den Debuggern eine bessere Template-Unterstützung, es wäre durchaus möglich, die Templates beim Debuggen optional mit aufgelösten Parametern anzuzeigen, das würde manchmal den Überblick vereinfachen, aber das hab ich noch nirgends gefunden. (Nicht das man die Typen nicht rausbekommt, geht mir nur um den Konfort.)

groovemaster

kingruedi schrieb:

Aber nennt mal bitte ein Killer Feature des VC++ Debuggers

Was ist für dich denn ein Killer Feature?
Oh, ich hab eines. Wie du vielleicht weisst, benutzt WinAPI für Fehlerwerte HRESULT. Wenn du so einen also hast, steht im Überwachungsfenster nicht irgendein nichtssagender Wert, sondern Klartext. Das nenn ich doch mal Killer Feature. So bleibt dir ständiges Suchen in der winerror.h erspart.

Zudem muss ich gestehen, dass ich bei einem Debugger keine Killer Features brauche. Man arbeitet damit idR wirklich nur in Extremfällen. Und der VC++ Debugger bietet (fast) alles, was man zum vernünftigen Arbeiten braucht:
- automatische Variablenüberwachung
- lokale Variablenüberwachung
- benutzerdefinierte Überwachung von Ausdrücken
- Überwachung von Prozessen, Threads und Modulen
- Call Stack
- Breakpoints
- x86 Register, FPU, MMX, SSE, 3DNOW, Flags
- Konsole
- umschalten zwischen Code und Assembly
- und noch einiges mehr, was ich noch nicht mal ansatzweise getestet habe

Und zu Power Off's Aussagen möchte ich nichts weiter sagen, da er offensichtlich nicht ganz auf dem Laufenden ist. Zudem bietet VC++ ebenfalls Code- und Projekt-Browsing, das ist aber nicht Debugger spezifisch. Und was das Ausführen von eigenem Code betrifft, da fehlt mir momentan noch das Verständnis, wozu man das brauchen könnte. Immerhin will ich den Code debuggen, den ich auch real habe und nicht irgendwelche Sachen zwischendurch ausführen lassen. Variablen und Speicher kann man ja auch so problemlos bearbeiten.

Hutzli_ schrieb:

Aber trotzdem gibt es schon noch einiges zu verbessern.

Dagegen ist ja auch nichts zu sagen. Nur kann ich mit dem VC++ Debugger momentan wunderbar leben, mit GDB nicht, weil ich dafür bisher einfach noch kein vernünftiges Frontend gefunden habe.

rüdiger

@groovemaster
Naja, dass kann wohl jeder vernünftige Debugger. Also sagen wir ein Killer Feature gibt es nicht, es geht mehr um Sympathien

Und was das Ausführen von eigenem Code betrifft, da fehlt mir momentan noch das Verständnis, wozu man das brauchen könnte. Immerhin will ich den Code debuggen, den ich auch real habe und nicht irgendwelche Sachen zwischendurch ausführen lassen. Variablen und Speicher kann man ja auch so problemlos bearbeiten.

Das hilft einem einfach bei der Fehleranalyse. Zum einen kann man so Funktionen mit Seiten-Effekten besser testen, weil man die Programmsituation ja vorgeben kann. Zum anderen kann man so direkt untersuchungen durchführen, ohne das man sich einen Testcode schreiben muss.

groovemaster

kingruedi schrieb:

Naja, dass kann wohl jeder vernünftige Debugger.

Mit dem GDB hab ich sowas zB nicht mal ansatzweise hinbekommen, aber du kannst mich gerne eines Besseren belehren und mir dafür ein vernünftiges Frontend geben. Es geht ja nicht nur um die einzelnen Features selbst, sondern auch darum, wie man diese handeln kann.

kingruedi schrieb:

Das hilft einem einfach bei der Fehleranalyse. Zum einen kann man so Funktionen mit Seiten-Effekten besser testen, weil man die Programmsituation ja vorgeben kann. Zum anderen kann man so direkt untersuchungen durchführen, ohne das man sich einen Testcode schreiben muss.

Nunja, ich muss gestehen, dass ich für sowas bisher gut ohne das Ausführen von benutzerdefiniertem Code ausgekommen bin. Entweder man ändert sich entsprechende Zustände (Daten) oder setzt den IP an die gewünschte Stelle.
Ich finde auch nicht, das sowas zu den Kernfeatures eines Debuggers gehört. Wenn man sich zB mal einen puren, nicht sprachspezifischen Debugger anschaut, zB Olly, wie will man denn dort sowas implementieren? Bzw anhand welcher Kriterien will man denn sowas implementieren? Einfach die Syntax einer Sprache adaptieren oder einfach eine neue erfinden? Oder doch nur Assembler? Wäre irgendwie sinnlos, oder? Und wie sieht es dann mit dem Funktionsumfang aus?
Zudem ist sowas bei Compilersprachen recht aufwändig, da sollen sich die Entwickler lieber darauf konzentrieren, die wirklich wichtigen Features weiter zu verbessern. Ich sehe bisher zumindest noch keinen grossen Nachteil, wenn ein Debugger sowas nicht anbietet. Kann aber auch daran liegen, dass mir einfach die Erfahrung damit fehlt.

rüdiger

Das ist eben ein gutes Zusatzfeature. So etwas unterscheidet eben gute Debugger von gewöhnlichen Debuggern. Deswegen hab ich ja auch beim VC++ Debugger nach einem Killerfeature gefragt

Gute Frontends für den GDB sind Insight, KDbg und DDD.

Ansonsten bieten die GCC kompatiblen IDEs idr. auch GDB Support an. zB GNU/Emacs

groovemaster

Oh, ich hätte vielleicht dazu schreiben sollen, dass ich was für Windows suche.

Power Off

groovemaster schrieb:

Wenn man sich zB mal einen puren, nicht sprachspezifischen Debugger anschaut, zB Olly, wie will man denn dort sowas implementieren?

Ein Sprachunabhängiger Debugger liest einfach die Debug-Segmente aus dem ausführbaren Programm aus. Bei zeilenweisen Debug-Informationen steht dann z.B. der Quelltext der Programmzeile, die den Fehler erzeugt hat, mit im Debug-Segment (bzw. ein Verweise auf die Quelldatei und eine Zeilennumer).

Symbolinformationen stehen auch im Debug-Segment (manchmal auch im Code-/Datensegment). D.h. der Debugger kann dann die Adressen von globalen Variablen und Funktionen ermitteln (nur, die keine static linkage haben).

Das kann durchaus reichen, um einen halbwegs vernünftigen Debugger auf die Beine zu stellen. Man kommt halt dann nicht an lokale Variable dran, außer man vergleicht manuell den Source und den jeweiligen Stackframe / Registersatz. Aber es lassen sich z.B. ein Call-Stack anlegen und auch globale Variable auslesen (über einen Memory Dump).

Manche Debug-Formaten können auch weitergehende Debuginformationen sprachunabhängig codieren.

Oder ein Debugger bringt Syntax Analyzer für die gängigsten Sprachen mit und parst die in der Debug-Information angegebene Quelldatei.

(so oder so ähnlich dürften andere Debugger wie GDB oder der MS Debugger auch funktionieren)

groovemaster

Erstmal ein teilweises nö. Eine Executable muss keine Debug Infos enthalten, zudem sind diese nicht standardisiert. Und zweitens, was hat das mit der Implementation eines Interpreters zu tun?

Power Off

groovemaster schrieb:

Erstmal ein teilweises nö. Eine Executable muss keine Debug Infos enthalten, zudem sind diese nicht standardisiert. Und zweitens, was hat das mit der Implementation eines Interpreters zu tun?

Ein Syntax Analyzer ist kein Interpreter. Er zerlegt den Quelltext in eine interne Form, meist einen Syntax-Baum.

Wenn im Executable keine Debug-Infos vorhanden sind, können alle Debugger nur noch den Assembler-Code von Code-Segment bzw. die Rohdaten in Datensegmenten anzeigen. Benutzer von IDEs merken das meist nicht, weil sie ihre Projekte immer als Debug-Projekte compilieren.

Die Debug-Informationen sind sehr wohl standardisiert. Z.B. Microsoft VC++ verwendet ein von COFF abgeleitetes Format, kann aber auch andere Formate erzeugen.

groovemaster

Power Off schrieb:

Ein Syntax Analyzer ist kein Interpreter.

Ich dachte es geht darum, benutzerdefinierten Code ausführen zu lassen? Davon war zumindest die Rede. Einen "Syntax Analyzer" besitzt der VC++ Debugger zB auch.

Power Off schrieb:

Die Debug-Informationen sind sehr wohl standardisiert. Z.B. Microsoft VC++ verwendet ein von COFF abgeleitetes Format

Was aber nicht COFF kompatibel ist, afaik. Ergo, es gibt kein einheitliches Debug Format also kein einheitlicher Standard. Letztendlich macht das jeder Compiler wie er lustig ist, auch wenn man natürlich ein definiertes Format verwenden kann, wie zB COFF.

kartoffelsack

hab hier zwei Sachen gelesen, die der VC++ haben soll:

Memory-Breakpoint: Wo, wie? Unterbricht er, wenn sich der Wert an einer Adresse ändert? Wie mach man das???

Profiler: Wie schalt ich bei VC++ 7.1 (professional) den Profiler an? Weiß nur, dass der 6er einen hatte, hab jahrelang mit dem BCB gearbeitet und mich gefreut, als wir auf VC++7.1 umgestiegen sind. Jetzt find ich aber nirgends den Profiler.

kartoffelsack schrieb:

hab hier zwei Sachen gelesen, die der VC++ haben soll:

Memory-Breakpoint: Wo, wie? Unterbricht er, wenn sich der Wert an einer Adresse ändert? Wie mach man das???

Profiler: Wie schalt ich bei VC++ 7.1 (professional) den Profiler an? Weiß nur, dass der 6er einen hatte, hab jahrelang mit dem BCB gearbeitet und mich gefreut, als wir auf VC++7.1 umgestiegen sind. Jetzt find ich aber nirgends den Profiler.

kann ich dir beides nur beim 6er erklärn