Verständnis ASM. Warum funktioniert das in Windows?

Question

Ich und ein paar Freunde fummeln an einem sehr seltsamen Thema. Wir haben einen Crash in unserer Anwendung innerhalb eines kleinen Assembler-Teils (der den Prozess beschleunigt) entdeckt. Der Fehler verursacht wurde, indem er mit dem Stackpointer Hantieren und nicht am Ende zurückzusetzen, sah es wie folgt aus:

push  ebp 
mov   ebp, esp 

; do stuff here including sub and add on esp 

pop   ebp 

Wenn es richtig sollte es wie folgt geschrieben werden:

push  ebp 
mov   ebp, esp 

; do stuff here including sub and add on esp 
mov   esp,ebp 
pop   ebp 

Nun, was unser Mindbreak ist: Warum funktioniert das in Windows? Wir haben den Fehler gefunden, als wir die Anwendung auf Linux portiert haben, wo wir auf den Absturz gestoßen sind. Weder bei Windows noch bei Android (mit dem NDK) traten Probleme auf und wir hätten diesen Fehler nie gefunden. Gibt es eine Stackpointer-Wiederherstellung? Gibt es einen Schutz gegen Missbrauch des Stackpointers?

Answer 1

Die ebp ESP-Verwendung, heißt ein Stack-Frame, und ihr Zweck ist es, Variablen auf dem Stapel zuzuordnen, und danach haben Sie eine schnelle Möglichkeit, den Stapel vor der ret Anweisung wiederherzustellen. Alle neuen Versionen der x86-CPU können diese Anweisungen zusammen komprimieren, indem sie stattdessen Anweisungen zum Betreten/Verlassen verwenden.

esp ist der tatsächliche Stack-Zeiger, der von der CPU verwendet wird, wenn Push/Pop/Call/Ret ausgeführt wird. Ebp ist ein Benutzer-manipulierter Basiszeiger, mehr oder weniger alle Compiler verwenden dies als einen Stapelzeiger für lokalen Speicher.

Wenn die Anweisung mov esp, ebp fehlt, verhält sich der Stack fehlerhaft, wenn es die CPU pop ebp erreicht, wenn die CPU die pop ebp erreicht, aber nur dann.

Answer 2

es scheint, die Compiler Pflege Ihres Stapels nimmt in den Fenstern:
Der einzige Weg, ich ist vorstellen kann:
Microsoft Visual C besondere Pflege von Funktionen nimmt die B {__ stdcall}. Da die Anzahl der Parameter zur Kompilierzeit bekannt ist, codiert der Compiler die Bytezahl des Parameters im Symbolnamen selbst.
Die __stdcall-Konvention wird hauptsächlich von der Windows-API verwendet und ist etwas kompakter als __cdecl. Der Hauptunterschied besteht darin, dass jede gegebene Funktion eine fest codierte Menge von Parametern hat, und diese kann nicht von Anruf zu Anruf variieren, wie es in C möglich ist (keine "variadischen Funktionen").
sehen:
http://unixwiz.net/techtips/win32-callconv-asm.html
und:
https://en.wikipedia.org/wiki/X86_calling_conventions