Hi,
I wonder whether is there any actual difference or not between the following sample pieces of code in terms of code-safe:
Is it safe to fill the stack first, then adjust the ESP (the former case)?
I know it is not safe in real mode at all (because an interrupt can occur between MOV and SUB, resulting in destroyed value at ), but I'm not utterly sure how it is in protected mode.
My basic question is: can we say that it is *always* safe?
I'm asking this question in regards to discussion here.
I wonder whether is there any actual difference or not between the following sample pieces of code in terms of code-safe:
mov ,eax ;; fill first
sub esp,4 ;; adjust later
opposite to:
sub esp,4 ;; adjust first
mov ,eax ;; fill later
Is it safe to fill the stack first, then adjust the ESP (the former case)?
I know it is not safe in real mode at all (because an interrupt can occur between MOV and SUB, resulting in destroyed value at ), but I'm not utterly sure how it is in protected mode.
My basic question is: can we say that it is *always* safe?
I'm asking this question in regards to discussion here.
I've always used ESP for whatever I want in my threads - I don't use the stack and it loops until thread is terminated - sure hope it is okay. :)
So, the question can also be stated: does something else in your thread use the stack? I don't know the real answer, but I assume no. Certainly, we do not want to CALL anything prior to ESP adjustment.
So, the question can also be stated: does something else in your thread use the stack? I don't know the real answer, but I assume no. Certainly, we do not want to CALL anything prior to ESP adjustment.
in protected mode your app will usually run in ring 3. Any hardware interrupt will cause a switch to ring 0 which should use a different stack. So it should be safe.
For exceptions things aren't that clear. For example, Int 3/Int 1 in IDT may be set to a ring 3 gate (well that't pretty unlikely in winxp/win9x, but possible). This would destroy dword at
For exceptions things aren't that clear. For example, Int 3/Int 1 in IDT may be set to a ring 3 gate (well that't pretty unlikely in winxp/win9x, but possible). This would destroy dword at
Thanks guys.
I've once seen the following code here on the board:
I've remembered it was posted by some experienced coder and that he surely knew why he put the SUB before the MOVs, even though this way can rise a dependency. I've searched and it was posted by you, bitRAKE :-D
japheth, you've pointed interesting thing out. Can you say how are int1/int3 handlers redirected to a ring3 debugger (like Olly) actually?
What about kernel-mode debuggers? Is it a similar situation?
I've once seen the following code here on the board:
sub esp, 16
nop
mov [esp], eax
mov [esp+4], ebx
mov [esp+8], ecx
mov [esp+12], edx
I've remembered it was posted by some experienced coder and that he surely knew why he put the SUB before the MOVs, even though this way can rise a dependency. I've searched and it was posted by you, bitRAKE :-D
japheth, you've pointed interesting thing out. Can you say how are int1/int3 handlers redirected to a ring3 debugger (like Olly) actually?
What about kernel-mode debuggers? Is it a similar situation?
Be careful when you debug an application with Visual Studio 2005 Beta (Whidbey). The debugger sometimes assumes that esp is pointing to a valid stack (see http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=fcbc1d6a-398f-4d3c-b880-a806ef6b4119 )
Be careful when you debug an application with Visual Studio 2005 Beta (Whidbey). The debugger sometimes assumes that esp is pointing to a valid stack (see http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=fcbc1d6a-398f-4d3c-b880-a806ef6b4119 )
Interesting - that's a proof that some debuggers could use the stack of debbuged app! Could you try whether the debugger changes the stack of debugged app under stack top address, where the stack seems not to be used by the app?
No, the debugger doesn't touch the memory above esp (otherwise nothing would work :))
No, the debugger doesn't touch the memory above esp (otherwise nothing would work :))
I meant under (below) stack top, at lower addresses :)
Actually I would like to know, if you'd do:
mov ,eax ; insert the value below last really used address
does the debugger overwrite this value?
> japheth, you've pointed interesting thing out. Can you say how are
> int1/int3 handlers redirected to a ring3 debugger (like Olly) actually?
Only by direct access to the IDT. So this surely is bad programming practice, but sometimes necessary. For example:
- win9x has a bug in the debugging support sometimes causing debug traps to no reach a debugger. With int 1 going straight to the debugger this is no problem.
- to debug switches from 32bit to 16bit code - or protected mode to real mode - and vice versa in win9x you need a kernel debugger - or a ring 3 debugger with IDT access.
a debugger for win32 apps like Olly doesnt need such things.
> int1/int3 handlers redirected to a ring3 debugger (like Olly) actually?
Only by direct access to the IDT. So this surely is bad programming practice, but sometimes necessary. For example:
- win9x has a bug in the debugging support sometimes causing debug traps to no reach a debugger. With int 1 going straight to the debugger this is no problem.
- to debug switches from 32bit to 16bit code - or protected mode to real mode - and vice versa in win9x you need a kernel debugger - or a ring 3 debugger with IDT access.
a debugger for win32 apps like Olly doesnt need such things.
Thanks guys.
I've once seen the following code here on the board:
I've remembered it was posted by some experienced coder and that he surely knew why he put the SUB before the MOVs, even though this way can rise a dependency. I've searched and it was posted by you, bitRAKE :-D
Old habits die hard. (c:I've once seen the following code here on the board:
sub esp, 16
nop
mov [esp], eax
mov [esp+4], ebx
mov [esp+8], ecx
mov [esp+12], edx
I've remembered it was posted by some experienced coder and that he surely knew why he put the SUB before the MOVs, even though this way can rise a dependency. I've searched and it was posted by you, bitRAKE :-D
No, the debugger doesn't touch the memory above esp (otherwise nothing would work :))
I meant under (below) stack top, at lower addresses :)
Actually I would like to know, if you'd do:
mov ,eax ; insert the value below last really used address
does the debugger overwrite this value?
Sorry, when I said "above esp" I meant at adresses inferior to esp (free stack space.) In your example the debugger will overwrite the value at .
In your example the debugger will overwrite the value at .
Thanks, that's what I've needed. He he, Visual Studio 2005 acts as old Turbo Debugger :)