eigener Debugger - Haltepunkte

[himitsu]

'nen Tag/Woche?

Wie gesagt, Debuggen selbst (also Variablen auslesen/ändern/sonstwas) nicht.
Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Das Grundgerüst bastl ich grad mal zusammen (ohne Haltepunkte), also Starten/Anhängen, Stoppen und Loggen,
um was zum Testen zu haben.

Ich glaub der StackTrace, beim Halt, wird wohl das Größte.
In der Pipeline hab ich noch das Auslesen der TDS (in 'nem anderem Projekt) ... die DebugInfos von Windows/C++ bekomm ich problemlos über die API vom Windows (schon benutzt, um Stacktraces auszulesen, wobei ich da noch Programme wie tds2pdb dazwischen hab, wegen dem was Delphi fabriziert).

[Kas Ob.]

Zitat von himitsu:

'nen Tag/Woche?

Wie gesagt, Debuggen selbst (also Variablen auslesen/ändern/sonstwas) nicht.
Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Das Grundgerüst bastl ich grad mal zusammen (ohne Haltepunkte), also Starten/Anhängen, Stoppen und Loggen,
um was zum Testen zu haben.

With Titan Engine you can have your own prototype debugger in few hours, just build the UI.

[Kas Ob.]

One more thing about the Debugger Loop mentioned and recommended in https://learn.microsoft.com/en-gb/wi...er-s-main-loop

You can see that the full loop is already and fully taken care of in TitanEngine, including break points and threading
https://github.com/x64dbg/TitanEngin...gLoop.cpp#L513

[freimatz]

Zitat von himitsu:

Ich glaub der StackTrace, beim Halt, wird wohl das Größte.

http://help.madshi.net/madStackTraceUnit.htm

[himitsu]

Nee nee, nicht im Programm, sondern in meinem "Debugger", von der anderen Anwendung
(wie im Delphi, da der Stacktrace, vom Programm)


* Grundstruktur der Grundfunktionen erstmal überlegt
* zwei "einfache" Testanwendungen gebastelt (um die Funktionen des Debuggers ausprobieren zu können)
* starten/stoppen der Testanwendung
* Prozesse auflisten (kommt heute dran)

[himitsu]

* Also, bezüglich Haltepunkten hab ich noch nichts angefangen.
* Ich kann sie empfangen, wenn sie im Zielprogramm explizit ausgelöst werden. (BebugBreak; oder asm int 3 end; )
* Haltepunkte sind "Exceptions".
* Die Detailbehandlung von Exceptions hab ich bisher nur rudimentär. (keine Detailinfos und Messages)
* beim Auslesen vom Stack bricht es immer vorher ab. (gleich nach 1 oder 3-6 Sprüngen ... mein Limit steht auf 10, aber vorher kommt schon als ReturnAddr eine 00000000 vorbei)
* Nein, es gibt noch keine Namensauflösungen im Stack, also nur die Adresse, um zu sehn, ob überhaupt was kommt. (WalkStack ... noch nicht WalkStack64 oder WalkStackEx oder ...)
* aktuell nur 32 Bit Debugger mit 32 Bit Testprogramm getestet (erstmal das zum Laufen bringen und dann weiter)

* DebugInfos auslesen und dann vielleicht Haltepunkte setzen gibt es noch nicht ... bin noch hart am Kämpfen, mit den Grundfunktionen

* Dokumentation (Microsoft) und Artikel/Tutorials sind teilweise sogar in sich schon wiedersprüclich.
* So weiß ich noch nicht welche Handles ich wann freigeben darf/soll/muß.
* Jedenfalls ist da garantiert bestimmt noch was falsch
. * wenn der Prozess endet, dann verschwindet er und teilweise sein Fenster nicht sofort (erst wenn mein DebugThread oder ganzer Debugger endet)
. * wenn ich im Debugger den Prozess oder das Debuggen auf verschiedenste Weisen beende, dann verschwindet es auch nicht
. . bin mir fast sicher, dass ich noch irgendwo ein Handle auf den Prozess/Thread offen habe und das alles festhält

* Delphi hat enorme Probleme mit dem Debuggen von Consolenanwendungen
. ich kann extrem leicht immer einen "schweren Ausnahmefehler" im Delphi-Debugger und der IDE auslösen (mit einem einfachen Programm, noch ohne selbst Debugger spielen zu wollen)
Screenshot 2024-06-22 114219.png
* zusammen mit Parnassus wird es noch viel extremer
* besonders auf Windows 11 mit dem Terminal knallt es am Besten ... im Gegensatz zu Windows 10 und ohne dass das neue Terminal installiert ist
> Debuggen der Konsolenanwendung starten
> in einen Haltepunkt laufen
> im angehaltenen Zustand das Konsolenfenster schließen
> nach einigen Sekunden beendet sich dann der ConsoleHost (manchmal nimmt er auch die eigene EXE mit)
> Delphi bekommt natürlich nichts mit
> wird danach dann Fortsetzen oder ein STOP im Debugger ausgeführt, war's das
. > der Debugger raucht ab und Delphi lässt sich fast nicht mehr beenden (will dabei immer den Debugger beenden, aber dabei knallt es)
. > mit viel Glück wird dann ach nichts gespeichert (der gespeicherte Desktop ist im Arsch) ... Haltepunkte und "geöffnete Dateien" werden vergessen
. > einmal war auch das ganze noch ungespeicherte Projekt weg (nichtmal __history und __recovery vorhanden) ... da die BDS aber auch garnicht mehr reagierte hatte ich noch genug Zeit für einen Snapshot (Taskmanager) und dann in den 2 GB RAM wichtige Teile geborgen ... vielen Dank an HxD (keine Lust nochmal alles zu suchen und neu machen zu müssen)



Quellcodes aktuell vielleicht auf liebe Nachfrage.



* So, hab hier auch gleich endlich mal mit dem neuen Streaming der Console gespielt, gegenüber der alten ConsoleAPI.
* das Terminal reagiert ja auch teilweise anders, gegenüber der alten Console (CMD)
. * Eingaben landen standardmäßig sofort im ECHO (Anzeige) ... mitten in der laufenden Ausgabe und nicht, wie früher, erst dann, wenn die Console/Anwendung in den Eingabemodus wechselt
. * der Curso blinkt standardmäßig immer, auch wenn nichts eingegeben werden soll
. * Markieren und Anhalten geht nicht mehr ... läuft im Hintergrund weiter und wenn Programm fertig, dann geht das Terminal auch sofort zu (egal ob noch was markiert/angehalten ist)

* wenn ich den Prozess selbst starte, inkl. Debuggen, dann erhalte ich teilweise andere Ergebnisse, als wenn ich mich an ein laufendes Programm angänge.
. * einmal immer nur EINE StackAdresse oder auch Mehrere (aber immernoch nicht genug)
. * die Namen der EXE/DLLs sind anders C:\... oder \Device\HarddiskVolume3\...

* Hier mal paar Test-Aufrufe aus dem Delphi-Projekt:
> SuperMiniDebugger.exe -process <ID>
> SuperMiniDebugger.exe -process <NAME>
> SuperMiniDebugger.exe -process <MASK>
> SuperMiniDebugger.exe -executable <FILENAME> -all
> SuperMiniDebugger.exe -executable <FILEMASK> -all
> SuperMiniDebugger.exe -demo-executable -all
> SuperMiniDebugger.exe -help
Da wird dann auch zusätzlicher DBBUG-Code in meinem Debugger genutzt. (TestApp starten und PID suchen, anstatt das jedesmal selbst machen/suchen/eingeben zu müssen)
Screenshot 2024-06-22 112409.png



https://github.com/microsoft/terminal
https://learn.microsoft.com/de-de/windows/terminal/
https://apps.microsoft.com/detail/9n...hl=de-de&gl=DE

Ups, ein Fehler in der Logausgabe (letzer Screenshot).
Das "-process" mit dem langen Dateiname, inkl. Pfad, müsste "-executable" heißen.

[Uwe Raabe]

Zitat von himitsu:

Benötige nur die Meldungen vom Debugger, wann es wo vorbei kam.

Ich habe zwar immer noch nicht das große Ganze begriffen, worauf du hinaus willst, aber eine Meldung beim Durchlaufen eines Haltepunkts ohne dort wirklich anzuhalten bekommt man auch mit den Bordmitteln hin:

• Haltepunkt setzen
• Eigenschaften des Haltepunkts...
• Weitere...
• Anhalten abwählen
• Meldung protokollieren ausfüllen

Die Haltepunkte lassen sich auch in einem IDE-Plugin entsprechend setzen. Im DelphiCodeCoveragePlugin findest du ein Beispiel dazu.

[himitsu]

Funktional intern halt so, wie beim AQTime.

Allerdings (erstmal) keine Zeitmessung, sondern ein Tracing ... rückwirkend schauen was vorher und in welcher Reihenfolge gemacht wurde.
Oder einfach nur was innerhalb eines gewissen Zeitraums ausgeführt wurde, auch ohne Reihenfole.
Sowie ein Logging von Meldungen (Exceptions usw.)

Im Prinzip so, als wenn du im Delphi dauerhaft F7 drückst,
bis es irgendwo knallt oder anhält
und dann versuchst du dich zu erinnern, was vorher zuletzt für Zeilen ausgeführt wurden.
Funktionen rufen Funktionen auf -> im Stack zu sehn, aber

Code:

* Funktionsaufruf
  * weiterer Funktionsaufruf
    - usw.
      -
        - hier wird etwas Böses/Interessantes gemacht
      - end;
    - Code innerhalb gleicher Funktion/Ebene, wie das Nachfolgende
    * hier vielleicht das Except vom Try, oder einfach nur ein weiter Funktionsaufruf
      * hier bekomme ich vielleicht den Stacktrace aller/vieler * und sehe aber die - nicht mehr

Das Betrifft z.B. auch ausgelöste Events (PostMessage) aus, wo du im Event nicht wissen kannst, von wem das gekommen ist.
Beim SendMessage (innerhalb der eigenen Anwendung/Thread) müsste man es eigentlich erfahren können, aber da raucht das Auflösen vorher auch immer ab und du siehst nicht, wer das SendMessage aufgerufen hat.

[Uwe Raabe]

Damit sehe ich noch keine Anforderung, die mit den beschriebenen Bordmitteln nicht erfüllt werden kann.

Für Timing und Exceptions setze ich eher auf CodeSite anstatt Breakpoints - schon aus Performancegründen.

[Uwe Raabe]

Übrigens: Man kann im Eval-Ausdruck auch einfach einen Log-Call einsetzen.