flat assembler
Message board for the users of flat assembler.

Index > Windows > WIN64*X*.inc auto aligns RSP to 16 bytes

Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
That was added to facilitate the programmer's life or it is there because some other parts of the macro package relies on that?

All the 64-bit examples (none of them use .code because are not using the extended headers) start with this:
Code:
start:
sub rsp, 8    
Some people (this already happened to someone and I think it could happen to many else), added "sub rsp, X" on their entry point where X is either 8 or another number that assumes RSP is aligned to 8 bytes.

Also, perhaps this could be problematic if the entry point is a proc?
Post 08 Jan 2010, 19:58
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 09 Jan 2010, 12:48
View user's profile Send private message Visit poster's website Reply with quote
Pirata Derek



Joined: 31 Oct 2008
Posts: 259
Location: Italy
Pirata Derek
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)         
    
Post 09 Jan 2010, 13:23
View user's profile Send private message Send e-mail Reply with quote
charme



Joined: 08 Jan 2010
Posts: 22
charme
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
Post 09 Jan 2010, 13:43
View user's profile Send private message ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Pirata Derek: you forgot about LEAVE.
Post 09 Jan 2010, 13:53
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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)
Post 09 Jan 2010, 18:28
View user's profile Send private message Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
Pirata Derek wrote:
Why isn't ENTER instruction used instead of PUSH EBP.... ?
Probably 'cause it's slow and old. However, it's counterpart - leave - is only old. Or I think so, it shouldn't be too slow, GCC uses it.
Post 09 Jan 2010, 18:44
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 09 Jan 2010, 19:18
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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? Wink
Post 09 Jan 2010, 19:26
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
In case the clarification hided the bug (I saw your post before you edited it Wink), 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     
(Listing generated with Agner Fog's objdump that I stupidly didn't download earlier)
Code used:
Code:
.code
start: fastcall _start
ret

proc _start
        invoke  MessageBox, 0, _message, _caption, 0
        invoke  ExitProcess, eax
        ret
endp    
I think that in the 32-bit world the API function pointers also suffers of misalignment at times.
Post 09 Jan 2010, 20:22
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
LocoDelAssembly wrote:
In case the clarification hided the bug (I saw your post before you edited it Wink), there is actually a bug in PROC when there are no locals nor arguments.

Yes, I noted it. Smile

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.
Post 09 Jan 2010, 20:40
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Oh, and BTW, I think I should add some "proc" detection to ".end" macro.
Post 09 Jan 2010, 20:41
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
I think it would be better to remove the initial auto-alignment but the proc detection will have to be enough Razz
Post 09 Jan 2010, 20:48
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
LocoDelAssembly wrote:
I think it would be better to remove the initial auto-alignment but the proc detection will have to be enough Razz

It wouldn't go along with the purpose of ".end" macro. See the hello.asm.
Post 09 Jan 2010, 21:05
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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
Because of that now it will have to always align, however, the original purpose of .end was to establish the executable entry point and build the import table, but now on win64 it will make an extra step that was not needed in 32-bit: align the stack.
Post 09 Jan 2010, 21:25
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.