flat assembler
Message board for the users of flat assembler.
Index
> Windows > WIN64*X*.inc auto aligns RSP to 16 bytes |
Author |
|
Tomasz Grysztar 09 Jan 2010, 12:48
The Win64 fastcall convention requires the stack frame to be aligned at 16 bytes. Didn't you know that already? I'm pretty sure you participated in some threads discussing the Win64 calling convention.
LocoDelAssembly wrote: Also, perhaps this could be problematic if the entry point is a proc? The fact is, that the entry point IS a proc, and that's why you have to do at least "sup rsp,8" at startup. If you use "proc" macro to define the entry point instead, you won't have to do this manually, since "proc" will do it for you. |
|||
09 Jan 2010, 12:48 |
|
Pirata Derek 09 Jan 2010, 13:23
Why isn't ENTER instruction used instead of PUSH EBP.... ?
It is a single instruction that simplify the programmation, right? in the 64 bit case (upper posts) the instruction is: Code: Generic_procedure: enter (8 * number_of_parameters) , 0 .... ret (8 * number_of_parameters) |
|||
09 Jan 2010, 13:23 |
|
charme 09 Jan 2010, 13:43
it just ailgn the ret address..............but for the
call proc proc: sub rsp,8*(4) bcs you must init the minest stack for rcx rdx r8 r9 |
|||
09 Jan 2010, 13:43 |
|
Tomasz Grysztar 09 Jan 2010, 13:53
Pirata Derek: you forgot about LEAVE.
|
|||
09 Jan 2010, 13:53 |
|
LocoDelAssembly 09 Jan 2010, 18:28
OK, after walking on my knees to make this run on the computer with Win7 I have this:
Code: format PE64 GUI 5.0 include 'win64axp.inc' .code proc start local a:QWORD mov rax, _caption mov [a], rax int3 ; RSP MOD 16 = 8 invoke MessageBox, 0, _message, _caption, 0 ; ACCESS VIOLATION WHEN READING 0000000000000000 (THE EXCEPTIONS OCCURS INSIDE MESSAGEBOX invoke ExitProcess, eax endp .data _caption db 'Win64 assembly program',0 _message db 'Hello World!',0 .end start BUT this is OK: Code: format PE64 GUI 5.0 include 'win64axp.inc' .code proc start int3 ; RSP MOD 16 = 0; But I think it is a mistake in PROC when there is no locals nor args invoke MessageBox, 0, _message, _caption, 0 invoke ExitProcess, eax endp .data _caption db 'Win64 assembly program',0 _message db 'Hello World!',0 .end start Yes, I do know about the alignment but I think other programmers also know and could consider it when adjusting RSP to their needs. (There is no documentation and all the examples start with SUB RSP, 8) |
|||
09 Jan 2010, 18:28 |
|
Fanael 09 Jan 2010, 18:44
Pirata Derek wrote: Why isn't ENTER instruction used instead of PUSH EBP.... ? |
|||
09 Jan 2010, 18:44 |
|
Tomasz Grysztar 09 Jan 2010, 19:18
LocoDelAssembly: oh, now I understand what you mean. It's about the ".end" macro. I misunderstood you, because the win64axp package itself doesn't do anything like that. The ".end" macro won't work correctly with "proc" this way, of course.
|
|||
09 Jan 2010, 19:18 |
|
LocoDelAssembly 09 Jan 2010, 19:26
That was the reason I don't completely like this automatic alignment, since the extended headers are somewhat HLLish, it should actually work always with a proc as an entry point. Also, this may mislead programmers, you align the entry point, but if fastcall is used to call a custom proc (i.e. just a mere label), the auto-alignment them saw in the entry point won't be automagically applied to the entry of the custom proc and both, the entry point and the label are labels, and why start is special here?
|
|||
09 Jan 2010, 19:26 |
|
LocoDelAssembly 09 Jan 2010, 20:22
In case the clarification hided the bug (I saw your post before you edited it ), there is actually a bug in PROC when there are no locals nor arguments.
Also, although somewhat unrelated, do you think it would be good to do something about this? Code: Entry_point:; Function begin sub rsp, 8 ; 00401000 _ 48: 83. EC, 08 sub rsp, 32 ; 00401004 _ 48: 83. EC, 20 call ?_001 ; 00401008 _ E8, 00000005 add rsp, 32 ; 0040100D _ 48: 83. C4, 20 ret ; 00401011 _ C3 ; Entry_point End of function ?_001: ; Local function sub rsp, 32 ; 00401012 _ 48: 83. EC, 20 mov rcx, 0 ; 00401016 _ 48: C7. C1, 00000000 mov rdx, ?_003 ; 0040101D _ 48: C7. C2, 00402017(d) mov r8, ?_002 ; 00401024 _ 49: C7. C0, 00402000(d) mov r9, 0 ; 0040102B _ 49: C7. C1, 00000000 ; Note: Memory operand is misaligned. Performance penalty call near [rel imp_MessageBoxA] ; 00401032 _ FF. 15, 0000205C(rel) ; <<<<< add rsp, 32 ; 00401038 _ 48: 83. C4, 20 sub rsp, 32 ; 0040103C _ 48: 83. EC, 20 mov ecx, eax ; 00401040 _ 89. C1 ; Note: Memory operand is misaligned. Performance penalty call near [rel imp_ExitProcess] ; 00401042 _ FF. 15, 0000201E(rel) ; <<<<< add rsp, 32 ; 00401048 _ 48: 83. C4, 20 ret ; 0040104C _ C3 Code used: Code: .code start: fastcall _start ret proc _start invoke MessageBox, 0, _message, _caption, 0 invoke ExitProcess, eax ret endp |
|||
09 Jan 2010, 20:22 |
|
Tomasz Grysztar 09 Jan 2010, 20:40
LocoDelAssembly wrote: In case the clarification hided the bug (I saw your post before you edited it ), there is actually a bug in PROC when there are no locals nor arguments. Yes, I noted it. LocoDelAssembly wrote: Also, although somewhat unrelated, do you think it would be good to do something about this? Should be easy to fix - just add some alignment code to the "import" macro. I think it's worth it. |
|||
09 Jan 2010, 20:40 |
|
Tomasz Grysztar 09 Jan 2010, 20:41
Oh, and BTW, I think I should add some "proc" detection to ".end" macro.
|
|||
09 Jan 2010, 20:41 |
|
LocoDelAssembly 09 Jan 2010, 20:48
I think it would be better to remove the initial auto-alignment but the proc detection will have to be enough
|
|||
09 Jan 2010, 20:48 |
|
Tomasz Grysztar 09 Jan 2010, 21:05
LocoDelAssembly wrote: I think it would be better to remove the initial auto-alignment but the proc detection will have to be enough It wouldn't go along with the purpose of ".end" macro. See the hello.asm. |
|||
09 Jan 2010, 21:05 |
|
LocoDelAssembly 09 Jan 2010, 21:25
Oh, I didn't see this comment the last time I saw the example:
Quote: ; you can simply switch between win32ax, win32wx, win64ax and win64wx here |
|||
09 Jan 2010, 21:25 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.