flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > Bug in the 64-bit "proc" macro?

Author
Thread Post new topic Reply to topic
JPowersFairfax



Joined: 25 Jan 2012
Posts: 9
JPowersFairfax
The following code crashes because the local variables are not aligned on a 16-byte boundary. The "proc" macro is creating a "sub rsp, 0x20" in the prolog when it should be a "sub rsp, 0x28". I was stumped because whenever I placed an "invoke DebugBreak" ANYWHERE in the proc, it worked fine! I finally realized that the problem is that my proc does not contain any calls. If I add any call anywhere in my proc, I get the "sub rsp, 0x28", which is correct.

I think there is a problem in the "proc" macro (I'm using the "static_rsp_prologue" by the way!) where it does not align rsp properly if a proc contains no calls, and thus locals don't get 16-byte aligned like they should. I looked at the macro but couldn't understand enough of what I was looking at to see/fix the problem. I was able to work around the problem by just adding "uses rbx" to the proc line. (But putting an even number of registers in the "uses" phrase caused the misalignment again, of course.)

Code:
proc fast_block_cmp,buf_one,buf_two,byte_ct

   locals
      xmm6_preserve  rq 2
      xmm7_preserve  rq 2
   endl

   movdqa dqword [xmm6_preserve], xmm6
   movdqa dqword [xmm7_preserve], xmm7

   ;... SNIP ...    
Post 16 Aug 2014, 03:34
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
There is no guaranteed alignment for local variables, it is an additional constraint that may or may not be implemented in a prologue/epilogue variant. When the are some calls inside a proc, it is the fastcall standard that enforces alignment, but otherwise there is no such constraint (there would be if fasm's documentation defined it in such way that local variables would always be aligned to some specific boundary).

It might be a good idea to allow use of the "align" directive inside the "locals" block. I will keep that in mind.

In general, however, I encourage to create dedicated sets of prologue/epilogue/close macros when the ones that come in standard package do not provide features or rules that are needed for specific applications.
In this case you can modify the "static_rsp_prologue" macro (you can override it in your source, or use a different name and different setting for prologue@proc only), by modifying this fragment:
Code:
   if frame & (counter+loc shr 3+1) and 1 
    loc = loc + 8 
   end if    
If you remove the "frame &" text, the aligment should be performed even if there are no function calls inside the procedure.
Post 16 Aug 2014, 09:23
View user's profile Send private message Visit poster's website Reply with quote
JPowersFairfax



Joined: 25 Jan 2012
Posts: 9
JPowersFairfax
I figured out that removing "frame &" worked, but wasn't sure if I was breaking something else or not. Thanks for confirming that.

I searched the forum before posting my question. I posted it because I came across this exchange:

vid wrote:
Quote:
The problem is that in 32-bit case locals themselves are not guaranteed to be aligned on 16 byte boundary (only 4 byte one). You'd have to modify proc prologue to get such alignment.

How about 64-bit case? Do FASM macros quarantee usual 16-byte alignment for locals? (provided that function is called properly, eg RSP & 0xF = Cool?


Tomasz Grysztar wrote:
Yes, they do. Both the default and the static-RSP variant.


I guess you didn't see that he was asking about locals?
Post 16 Aug 2014, 15:36
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
JPowersFairfax wrote:
I guess you didn't see that he was asking about locals?
Yes, that reponse was wrong. The macros only guarantee alignment that is required by fastcall interface, and nothing more.
Post 16 Aug 2014, 17:41
View user's profile Send private message Visit poster's website 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.