Index
> Windows > 64 bit not understood sub rsp,8 !Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next |
| Author |
|
|
Ali.Z 22 Dec 2020, 08:34
i think some members here answered this multiple times, please refer to the 64-bit calling conventions. (msdn and wikipedia)
additionally a 32 bytes of shadow space may be required, besides that and since during the load time of your application the stack may not be aligned depending on Windows version; thus you cant always subtract 8 from RSP. instead subtract some 16 bytes value from RSP then bitwise AND SPL with F0h. Code: sub RSP,100h ; just for the sake of example and SPL,0F0h ; to ensure the alignment _________________ Asm For Wise Humans |
|||
22 Dec 2020, 08:34 |
|
|
Roman 22 Dec 2020, 08:39
Ali.Z
Quote: thus you cant always subtract 8 from RSP. And how do pushs ? |
|||
|
22 Dec 2020, 08:39 |
|
|
revolution 22 Dec 2020, 08:40
Okay.
So here is the situation. Start is unaligned, because you use the entry directive directly. After sub and then push the stack is unaligned. After the call the stack is aligned. This is a violation of the call standard. All procedure entries must be unaligned entry after the call, and the code must then align, usually with push rbp. Because you use proc this is done for you by the macro. Therefore the stack is not in the correct state. And KABOOM! To fix this, do not push a single value to the stack. Always push in pairs, or better yet, don't ever push, just use local variables. Last edited by revolution on 22 Dec 2020, 08:40; edited 1 time in total |
|||
|
22 Dec 2020, 08:40 |
|
|
Roman 22 Dec 2020, 08:40
Quote:
I understood this many pages ago 
And try say this problem. In 32 bit program no this problem ! When i do push double(dq value) i not get crash ! Last edited by Roman on 22 Dec 2020, 08:44; edited 1 time in total |
|||
|
22 Dec 2020, 08:40 |
|
|
revolution 22 Dec 2020, 08:42
So why are you asking the question if you already knew?
|
|||
|
22 Dec 2020, 08:42 |
|
|
Roman 22 Dec 2020, 08:45
I wanted to confirm my guess. Test program on others CPUs.
And know this is not my wrong code. And remember this again, after couple years. Last edited by Roman on 22 Dec 2020, 08:49; edited 1 time in total |
|||
|
22 Dec 2020, 08:45 |
|
|
revolution 22 Dec 2020, 08:47
The 32-bit call standard is completely different. You can't compare them.
|
|||
|
22 Dec 2020, 08:47 |
|
|
Roman 22 Dec 2020, 08:51
Quote: The 32-bit call standard is completely different. That is why i very surprised when my program 64 bit crash. I thinked the same must work in 64 bits. |
|||
|
22 Dec 2020, 08:51 |
|
|
Roman 22 Dec 2020, 08:55
But if fasmw have some function to get know align rsp or not.
And not do always in invoke sub rsp,20h and add rsp,20h Do smart sub rsp and add rsp. Its solve problem. My example work if write in proc vv: Code: proc vv sub rsp,20h-8 xor rcx,rcx mov rdx,text xor r8,r8 xor r9,r9 Call [MessageBox] add rsp,20h-8 ret text db 'some text',0 endp in code: push rax call vv pop rax |
|||
|
22 Dec 2020, 08:55 |
|
|
revolution 22 Dec 2020, 09:05
Just follow the rules and then you will have no problem.
Always have your stack aligned before doing call, then it always works, always. If you have random "fixed" entries then you get trouble. Code: ; rsp is aligned push rax ;unaligned call vv ; okay, because vv has a fixup in there pop rax ; aligned call vv ; KABOOM! |
|||
|
22 Dec 2020, 09:05 |
|
|
Roman 22 Dec 2020, 09:29
Quote:
I agree and that's why I started talking about a smart mechanism in fasmw 64 bits. Fasmw must follow rsp and know rsp aligned or not. And put right x value in sub rsp,x |
|||
|
22 Dec 2020, 09:29 |
|
|
revolution 22 Dec 2020, 09:33
No.
fasm does what you tell it to do. Just follow the rules. If you have all those random stack adjustments with push then you get problems. Don't do it. Stop doing it. Never do it. Then all will work fine, no need for any special unruly code to "fix" the problems you created. |
|||
|
22 Dec 2020, 09:33 |
|
|
Roman 22 Dec 2020, 09:34
Quote:
Do it but remember this
And how i sayed best solution not do push rax and pop rax. Do mov [tmpRegs],rax Or macro NewPush reg { mov [tmpReg#reg],reg } Last edited by Roman on 22 Dec 2020, 09:45; edited 3 times in total |
|||
|
22 Dec 2020, 09:34 |
|
|
revolution 22 Dec 2020, 09:38
Yes. Use local variables. Then you get a nice name attached, and no more problems.
|
|||
|
22 Dec 2020, 09:38 |
|
|
Roman 22 Dec 2020, 09:42
Now you see too.
push and pop in 64 bits get problems. |
|||
|
22 Dec 2020, 09:42 |
|
|
revolution 22 Dec 2020, 09:46
You only get problems if you don't understand what is happening.
I said: Don't use random push/pop. |
|||
|
22 Dec 2020, 09:46 |
|
|
Roman 22 Dec 2020, 09:59
Quote: You only get problems if you don't understand what is happening. I understood, don't be angry. I try this in fasmw 1.73 : ;illegal local tmpReg:dword very fanny ;but compile ok if local tmpReg:DWORD Code:
proc v2
local tmpReg:DWORD
mov dword [tmpReg],eax
Msg 'f'
mov eax,[tmpReg]
ret
endp
|
|||
|
22 Dec 2020, 09:59 |
|
|
revolution 22 Dec 2020, 10:05
That is normal. What do you find "fanny"?
|
|||
|
22 Dec 2020, 10:05 |
|
|
Ali.Z 22 Dec 2020, 10:14
Roman wrote: local tmpReg:dword because its defined in procXX.inc as upper case. _________________ Asm For Wise Humans |
|||
|
22 Dec 2020, 10:14 |
|
| Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9 Next < Last Thread | Next Thread > |
Forum Rules:
|