eigener Debugger - Haltepunkte

[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.