flat assembler
Message board for the users of flat assembler.
Index
> Macroinstructions > safe invoke macro |
Author |
|
shoorick 28 Nov 2008, 12:24
it would be not bad to make this safe int3 inserting conditional, depending on presence of DEBUG_VERSION or so
|
|||
28 Nov 2008, 12:24 |
|
revolution 28 Nov 2008, 13:10
shoorick wrote: it would be not bad to make this safe int3 inserting conditional, depending on presence of DEBUG_VERSION or so Code: match any,DEBUG_ME {include 'my_safe_calls.inc'} |
|||
28 Nov 2008, 13:10 |
|
baldr 28 Nov 2008, 15:00
shoorick,
What's the point of having extra wrapper for every function call without added functionality? skykrnl, If function returns, it's too late to check for stack balance (it supposedly ret using address put on stack with call, at least for common case). Test for ccall macro correctly adjusting esp? |
|||
28 Nov 2008, 15:00 |
|
LocoDelAssembly 28 Nov 2008, 16:40
Quote:
Why? It will return successfully even if the retn operand didn't match with the total size of the arguments.* About ccall yeah, it is wrong, the only case in which int3 will not be executed is when the proc is parameterless... *I'm assuming here that stack imbalance is the only violation expected, EDI preservation is assumed. [edit]I'm wrong about ccall, I forgot that it adjusts the stack automatically after return [/edit] Last edited by LocoDelAssembly on 28 Nov 2008, 17:30; edited 1 time in total |
|||
28 Nov 2008, 16:40 |
|
revolution 28 Nov 2008, 16:46
LocoDelAssembly wrote: *I'm assuming here that stack imbalance is the only violation expected, EDI preservation is assumed. Code: macro ccall proc,[arg] { common local ..next,..ohshit push edi esi ebx ebp mov edi, esp mov esi, esp mov ebx, esp mov ebp, esp not ebx not ebp ccall proc,arg not ebx not ebp cmp edi, esp jnz ..ohshit cmp esi, esp jnz ..ohshit cmp ebx, esp jnz ..ohshit cmp ebp, esp jz ..next ..ohshit: int3 ..next: pop ebp ebx esi edi } |
|||
28 Nov 2008, 16:46 |
|
LocoDelAssembly 28 Nov 2008, 17:41
If you can't even assume that it will at least respect register preservation then I think that using a global variable to store ESP would be better.
I suppose that the intent of these macros is to guard the code against a calling convention mismatch, not a half stack protection as I had in mind in my first post (thinking of it in that way makes sense to the way in which the macros are implemented). |
|||
28 Nov 2008, 17:41 |
|
revolution 29 Nov 2008, 01:35
LocoDelAssembly wrote: If you can't even assume that it will at least respect register preservation then I think that using a global variable to store ESP would be better. |
|||
29 Nov 2008, 01:35 |
|
LocoDelAssembly 29 Nov 2008, 02:03
Quote:
Use access synchronization then (or use TLS). |
|||
29 Nov 2008, 02:03 |
|
baldr 29 Nov 2008, 07:20
LocoDelAssembly,
Access syncronization? I.e. block thread 1 in ccall/stdcall func1 each time ccall/stdcall func1 successfully acquired sync. object in thread 2 (I assume per-function synchronization object), which then was preempted before sync. object was released? TLS seems much better. |
|||
29 Nov 2008, 07:20 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.