Ich habe ein sehr rechenintensives Modul, in dem ich Stack-Tracing hinzugefügt habe, um bestimmte Probleme zu finden. Obwohl die Anwendung langsamer ausgeführt werden darf, wenn diese Stapelverfolgung aktiviert ist, darf sie nicht zehnmal langsamer ausgeführt werden. Aus diesem Grund verwende ich nicht die StackWalk-Routinen aus DBGHELP.DLL, sondern gehe den Stapel selbst mit den Frame-Zeigern durch (daher verwende ich die Compiler-Option Frame Pointer Omission nicht).

In den meisten Fällen funktioniert das Abrufen des Aufrufstapels ordnungsgemäß und ist sehr schnell. In einigen Fällen schlägt meine Logik jedoch fehl, da einer der Frame-Zeiger auf eine Adresse außerhalb des Stapels zeigt (nicht viel, nur ein bisschen).

Ich weiß, dass dies wahrscheinlich irgendwo ein Fehler ist, aber um meinen Code sicherer zu machen, muss überprüft werden, ob ein Frame-Zeiger auf eine Speicherstelle im Stapel des aktuellen Threads verweist oder nicht. Die Anwendung ist 64-Bit und läuft unter Windows.

Der Code beiWie erhalte ich Thread-Stack-Informationen unter Windows? löst wahrscheinlich das Problem, aber da dies andere Funktionen aufruft, wird mein Code wahrscheinlich viel langsamer ausgeführt (um ehrlich zu sein, ich habe es nicht getestet).

Ich habe auch Inline-Assembler-Code gefunden, der den Trick ausführen sollte (http://nasutechtips.blogspot.com/2011/01/thread-information-block-tib-and-fs.html), aber Inline-Assembly wird vom 64-Bit-C ++ - Compiler von Microsoft nicht unterstützt.

Auch das __readfsqword scheint auf 64-Bit nicht zu funktionieren.

Haben Sie noch weitere Vorschläge, wie Sie die TIB so schnell wie möglich auf 64-Bit bringen können?