eigener Debugger - Haltepunkte

[Kas Ob.]

Sorry !!

I missed the link
https://stackoverflow.com/questions/...ruction-on-x86

[himitsu]

Also, in den DR-Registern soll man wohl "je einen Haltepunkt" angeben können ... noch nicht probiert, aber das wären eh zu wenige

Das Trap-Flag einfach so zu setzen, hat keine Wirkung,

Delphi-Quellcode:

hMainThread := OpenThread(…, MainThreadID);
GetThreadContext(hThread, Context);
Context.EFlags := Context.EFlags or $0100;  // Trap-Flag (TF)
SetThreadContext(hThread, Context);
CloseHandle(HThread)

jedenfals nicht, wenn ich es in meinem Debugger mache (Taste [S] während des Debugging).

In der TestApp gesetzt, bzw. während eines Debug-Ereignisses, geht es,
aber bleibt dann auch irgendwann wieder aus und es stoppt. (siehe BreakPoint- oder SingeStep-Taste in der TestApp)

http://fnse.de/MiniDebugger.7z
SuperMiniDebugger.exe -demo-executable -all

PS: In der -help die DebugTasten nicht aktualisiert ... siehe Console, zu Beginn des Debuggens (hochscrollen)

[Kas Ob.]

Looks nice and working fine, though the source is not XE8 friendly due the inline variables and may be missing constants.

Question :
Why the overhead of keep opening the (a) thread and closing its handle ?!!

You have in the debugger loop an very useful events CREATE_THREAD_DEBUG_EVENT, and EXIT_THREAD_DEBUG_EVENT, so build a list or dictionary and do the open/close only once, this should help in speeding the trace.

As for the trap bit in the EFlags:
Single step is hardware generated interrupt same as hardware breakpoints, but for the single step to work these DR0-DR3 should be put to 0, in other words either you have enabled hardware breakpoints at specific addresses or single step, but not both at the same time.

May be just 0 to DR7 could be enough (zeroing all the bits) , but in my opinion the best is to clear DR0-DR3 and DR7, and think it will work every time.


ps: ran the binary and clicked on the buttons many times and couldn't see a failure.

ps2: i found this, it does confirm my recall about hardware breakpoints:
https://stackoverflow.com/questions/...p-all-the-time

[himitsu]

Zitat von Kas Ob.:

Why the overhead of keep opening the (a) thread and closing its handle ?!!

Weil WaitForDebugEventEx an diesen Stellen bloß die ThreadID liefert.

Ich finde es auch nicht wirklich schön, aber erstmal ist dieser Teil dort bloß zum Test drin
und dann abeitet hier alles noch sehr linear, ohne dass vieles zwischengespeichert wird.
* SuperMiniDebugger.dproj zum Test der Grundfunktionen
* und später im MiniDebugger.dproj dann inkl. erweitertem Handling

Ja, im Prinzip könnte man sich hier z.B. im CREATE_THREAD_DEBUG_EVENT das Handle klonen (DebugEvent.CreateThread.hThread) und bis zum EXIT_THREAD_DEBUG_EVENT aufheben.

Bzw. hier ist erstmal absichtlich noch nicht viel drin, um Dinge über längere Zeit zu behalten.
Primär wirklich erstmal nur die jeweiligen Events/Behandlungen für sich.
Daher kennen und logen die END-Events von DLL, Thread und Prozess auch keine Namen. (sie bekommen nur die ID, bzw. Adresse aus dem END-EventRecord)

[himitsu]

Weiß nicht, hab nun auch an den Debug-Registern rumgespielt, aber SingleStepping will nicht weiterlaufen.

Nja, hatte mich jetzt erstmal kurz abgelenkt und einen ersten Teil der Debuginfos erledigt.
Aus Microsoft-EXE/DLLs den Name und die GUID der PDB-Datei auslesen
und die PDB oder gewünschte Binaries von Microsofts DebugSymbol-Server downloaden.
(jetzt noch den halbangefangenen Code erledigen, um Dateinamen und Lines aus diesen Debuginfos auszulesen)

Hier gab es wenig mehr Infos und die auch noch verständlicher, auch wenn Microsoft das Format nie öffentlich dokumentiert hat ... aber bezüglich TDS dennoch einfacher.