Hello!
Suppose I'm in a windows thread. Can I discard a stack item
by a pop instruction or other, and be sure the value is not
overwritten by some "transparent" windows interrupt?
In other words: I own locals above esp, otherwise my program
couldn't reliably run, but what about addresses (reasonably
close by) below esp?
push 0
mov eax, esp
lea esp, ; discard pushed 0
;
; some instructions here
; but not using stack (no call, ret, pop etc.)
;
mov eax, ; always zero?
lea esp, ; do I reclaim valid data?
Suppose I'm in a windows thread. Can I discard a stack item
by a pop instruction or other, and be sure the value is not
overwritten by some "transparent" windows interrupt?
In other words: I own locals above esp, otherwise my program
couldn't reliably run, but what about addresses (reasonably
close by) below esp?
push 0
mov eax, esp
lea esp, ; discard pushed 0
;
; some instructions here
; but not using stack (no call, ret, pop etc.)
;
mov eax, ; always zero?
lea esp, ; do I reclaim valid data?
For your code, the 0 value will not change. So long you do not fool with the stack, the data should remain. Just remember that as long as your esp is smaller than the address on the stack that you want to preserver, the data will not be overwritten.
Yeah, during interrupts, a different stack is used. The program stack is not touched.
there's nothing that *guarantees* this, though. It's probably like this in practice on all existing and future windows versions, but it's a pretty bad thing to depend on - and there isn't really any reason for it either. You're not really "reclaiming" any space just by fiddling with esp, the memory pages from the stack will still be committed (dunno if it will eventually be decommitted by a lazy thread, or if it will remain committed until end of thread, though...)
Thanks to all three of you to reply!
I'll explain what this is all about:
16 dwords are reserved locals, pointed to by ebp.
Subroutines are set in place to operate on either
the stack, or the block of up to 16 locals.
The block needed is selected by an xchg ebp, esp
before the call.
So sometimes, esp is the real esp and all is ok.
In the other case though, esp is above a block
of data I need to keep uncompromised.
I'm playing with a virtual dual stack machine, where you
can switch from one stack (x86 hardware stack) to the
other (locals block) keeping instruction semantics.
I'd like to avoid using thread local storage, and still
use multiple threads of my virtual machine.
F0dder, you're right, it's plain sloppy to rely on this.
How could I do the block switching fast and reentrant
in a different way?
I'll explain what this is all about:
16 dwords are reserved locals, pointed to by ebp.
Subroutines are set in place to operate on either
the stack, or the block of up to 16 locals.
The block needed is selected by an xchg ebp, esp
before the call.
So sometimes, esp is the real esp and all is ok.
In the other case though, esp is above a block
of data I need to keep uncompromised.
I'm playing with a virtual dual stack machine, where you
can switch from one stack (x86 hardware stack) to the
other (locals block) keeping instruction semantics.
I'd like to avoid using thread local storage, and still
use multiple threads of my virtual machine.
F0dder, you're right, it's plain sloppy to rely on this.
How could I do the block switching fast and reentrant
in a different way?
You have your locals on one side of esp, then you have the return eip of the function so it knows who called it and can return, and on the other side of esp there is the input params to the function. If you wanna play with that space just define enough input params and voila - the procedure stackframe will not begin until after the input params, so there you have it.