Posted By: TechMuc
profiling funktionen (assembler - deutsch) - 10/20/12 23:00
Hi,
Um es kurz zu halten vorneweg die Frage / das Problem: Ist es möglich die tatsächliche Adresse von wait(..) herauszufinden? Engine_GetFunc("wait") liefert nicht die Adresse die tatsächlich aufgerufen wird.
Länger und für das Verständnis wichtig: Ich bitte Sie auch hier kurz rüber zu fliegen. Ich denke ein solches Programm könnte der Lite-C Sprache sehr helfen
Ich schreibe aktuell einen sehr simplen Profiler für Lite-C. Der "Profiler" registiert zum jetztigen Zeitpunkt jeden Funktionsein- und austritt. Wird beispielshaft eine beliebige Lite-C User-Funktion aufgerufen, greift mein Coding an der entsprechenden Stelle ein - springt zu einer eigenen Funktion - und führt anschließend die User Funktion auf. Durch Manipulation des Stacks wird anschließend beim "Return" auf eine eigene Funktion zurückgesprungen. Für das Verständis: Dies funktioniert nicht durch Manipulation von Lite-C Coding sondern rein durch Änderung von Maschinenbefhlen / Assembler..
Dies klappt bis auf wenige Ausnahmen (siehe Overloaded Functions, anderer Thread) sehr gut.
Problemstellung ist der Scheduler / Wait. Um laufende (nicht aufgerufene) Funktionen zu überwachen muss der Scheduler überwacht werden. Im Folgenden ist das Konzept kurz an folgender Lite-C Funktion erklärt.
Bei Aufruf von test_2 durch den Compiler passiert folgendes:
test_2() --> forward auf meine Funktion --> Zurückleitung auf test_2() --> wait(1) wird ausgeführt / Funktion wird beendet und wieder fortgesetzt ohne das ich dies registrieren kann.
Passieren Soll:
test_2() --> forward auf meine Funktion --> Zurückleitung auf test_2() --> wait(1) --> Wait(1) wird intercepted und auf meine eigene Funktion weitergeleitet --> Echte Wait Funktion wird aufgerufen --> Funktion wird fortgesetzt und durch meine Funktion registriert.
Im Assembler sieht der Wait Aufruf in etwa wie folgt aus:
Wäre ich in der Lage auf die reale Position von wait zuzugreifen, könnte ich zweierlei machen:
1) Den Aufruf auf die reale wait Funktion abfangen um diese "Beendigung" der Funktion registrieren zu können. Im Anschluss könnte ich die reale Wait Funktion aufrufen um den Programmablauf nicht zu stören.
2) Durch eine sehr schnelle Analyse des Stacks könnte ich das weiterführende Coding erkennen (hier Adresse 02DF1A88). Auch hier wäre eine Ersetzung von 5 Byte ab Adresse 02DF1A88 zu Gunsten eines Jump Befehls zu "meiner" Registrierfunktion möglich. Die "alten" 5 Bytes würden an eine andere Stelle im Speicher verschoben und dort ausgeführt.
==> Problemstellung:
Es scheint nicht möglich zu sein, die reale Position von wait Acknex-Versionsunabhängig zu überprüfen.
Sowohl engine_getfunc("wait") in C++ als auch ein var test=&wait; in Lite-C lieferen die Adresse einer anderen Funktion die anscheinend nichts mit der "echten" wait Funktion zu tun hat.
==> Gibt es eine Möglichket die Echte WAIT Funktion zu bekommen?
Grüße und vielen Dank,
Timo Stark
Um es kurz zu halten vorneweg die Frage / das Problem: Ist es möglich die tatsächliche Adresse von wait(..) herauszufinden? Engine_GetFunc("wait") liefert nicht die Adresse die tatsächlich aufgerufen wird.
Länger und für das Verständnis wichtig: Ich bitte Sie auch hier kurz rüber zu fliegen. Ich denke ein solches Programm könnte der Lite-C Sprache sehr helfen
Ich schreibe aktuell einen sehr simplen Profiler für Lite-C. Der "Profiler" registiert zum jetztigen Zeitpunkt jeden Funktionsein- und austritt. Wird beispielshaft eine beliebige Lite-C User-Funktion aufgerufen, greift mein Coding an der entsprechenden Stelle ein - springt zu einer eigenen Funktion - und führt anschließend die User Funktion auf. Durch Manipulation des Stacks wird anschließend beim "Return" auf eine eigene Funktion zurückgesprungen. Für das Verständis: Dies funktioniert nicht durch Manipulation von Lite-C Coding sondern rein durch Änderung von Maschinenbefhlen / Assembler..
Dies klappt bis auf wenige Ausnahmen (siehe Overloaded Functions, anderer Thread) sehr gut.
Problemstellung ist der Scheduler / Wait. Um laufende (nicht aufgerufene) Funktionen zu überwachen muss der Scheduler überwacht werden. Im Folgenden ist das Konzept kurz an folgender Lite-C Funktion erklärt.
Code:
void test_2() {
globalvar = 1;
wait(1);
globalvar = 2;
return 2;
}
Bei Aufruf von test_2 durch den Compiler passiert folgendes:
test_2() --> forward auf meine Funktion --> Zurückleitung auf test_2() --> wait(1) wird ausgeführt / Funktion wird beendet und wieder fortgesetzt ohne das ich dies registrieren kann.
Passieren Soll:
test_2() --> forward auf meine Funktion --> Zurückleitung auf test_2() --> wait(1) --> Wait(1) wird intercepted und auf meine eigene Funktion weitergeleitet --> Echte Wait Funktion wird aufgerufen --> Funktion wird fortgesetzt und durch meine Funktion registriert.
Im Assembler sieht der Wait Aufruf in etwa wie folgt aus:
Code:
02DF1A7F push eax <-- enthält die 1 als Parameterübergabe 02DF1A80 mov eax,dword ptr [ebx+1194h] --> enthält die "globale echte adresse von wait 02DF1A86 call eax --> jump zu wait 02DF1A88 add esp,4 --> weiter in der Programmausführung.
Wäre ich in der Lage auf die reale Position von wait zuzugreifen, könnte ich zweierlei machen:
1) Den Aufruf auf die reale wait Funktion abfangen um diese "Beendigung" der Funktion registrieren zu können. Im Anschluss könnte ich die reale Wait Funktion aufrufen um den Programmablauf nicht zu stören.
2) Durch eine sehr schnelle Analyse des Stacks könnte ich das weiterführende Coding erkennen (hier Adresse 02DF1A88). Auch hier wäre eine Ersetzung von 5 Byte ab Adresse 02DF1A88 zu Gunsten eines Jump Befehls zu "meiner" Registrierfunktion möglich. Die "alten" 5 Bytes würden an eine andere Stelle im Speicher verschoben und dort ausgeführt.
==> Problemstellung:
Es scheint nicht möglich zu sein, die reale Position von wait Acknex-Versionsunabhängig zu überprüfen.
Sowohl engine_getfunc("wait") in C++ als auch ein var test=&wait; in Lite-C lieferen die Adresse einer anderen Funktion die anscheinend nichts mit der "echten" wait Funktion zu tun hat.
==> Gibt es eine Möglichket die Echte WAIT Funktion zu bekommen?
Grüße und vielen Dank,
Timo Stark
Wenn die "korrekte" (korrekt ist nichr ganz das richtige Wort hier