flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > Found bug in the 'cinvoke (fastcall)' macro

Author
Thread Post new topic Reply to topic
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
I'm pretty sure this is a bug in the 'invoke (fastcall)' macro, in that the first three parameters don't get loaded properly. You can download the code below. This code should compile in a stock fasmw17121 folder.


Description: Code example for 'invoke (fastcall)'
Download
Filename: CONSOLE.zip
Filesize: 9.09 KB
Downloaded: 131 Time(s)


_________________
Gimme a sledge hammer! I'LL FIX IT!
Post 22 Jul 2014, 16:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
Which invoke call are you referring to? There are 8 in total in the example you posted.
Post 22 Jul 2014, 18:11
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
revolution wrote:
Which invoke call are you referring to? There are 8 in total in the example you posted.


Code:
     cinvoke printf, _values, float qword [test_floats],\
                              float qword [test_floats + 8],\
                              float qword [test_floats + 16],\
                              float qword [test_floats + 24],\
                              float qword [test_floats + 32],\
                              float qword [test_floats + 40],\
                              float qword [test_floats + 48],\
                              float qword [test_floats + 56]    

_________________
Gimme a sledge hammer! I'LL FIX IT!
Post 22 Jul 2014, 19:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
MS has this to say:
If parameters are passed via varargs (for example, ellipsis arguments), then essentially the normal parameter passing applies including spilling the fifth and subsequent arguments. It is again the callee's responsibility to dump arguments that have their address taken. For floating-point values only, both the integer and the floating-point register will contain the float value in case the callee expects the value in the integer registers.
So actually the printf function is using the integer registers and ignores the xmm registers. So for the cinvoke fasm should be placing the data in both the xmm and integer registers.
Post 22 Jul 2014, 21:47
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
revolution wrote:
MS has this to say:
If parameters are passed via varargs (for example, ellipsis arguments), then essentially the normal parameter passing applies including spilling the fifth and subsequent arguments. It is again the callee's responsibility to dump arguments that have their address taken. For floating-point values only, both the integer and the floating-point register will contain the float value in case the callee expects the value in the integer registers.
So actually the printf function is using the integer registers and ignores the xmm registers. So for the cinvoke fasm should be placing the data in both the xmm and integer registers.


Damn, for a minute there I thought my post was deleted. That is a strange case, I thought all function calls were equal in 64bit. Sounds like you would need some kind of switch to let the cinvoke (fastcall) macro know about varargs functions.

_________________
Gimme a sledge hammer! I'LL FIX IT!
Post 22 Jul 2014, 22:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
vinvoke anyone?

For my code the only time I use cinvoke is with vararg calls so "fixing" cinvoke would be a suitable solution. But perhaps others use cinvoke also for other calls?

Of course as an interim fix you can just remove the 'float' keyword.
Post 22 Jul 2014, 22:58
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Quote:
Of course as an interim fix you can just remove the 'float' keyword.

Wish I would've thought of that, works like it should now.
Post 22 Jul 2014, 23:42
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
For my code the only time I use cinvoke is with vararg calls so "fixing" cinvoke would be a suitable solution. But perhaps others use cinvoke also for other calls?
I like this solution. It actually makes "cinvoke" keyword useful again in 64-bit world. I updated the package with a version that fixes it this way - if I document the information that 64-bit "cinvoke" and "ccall" should only be used for vararg functions, it should be an OK solution IMO.
Post 23 Jul 2014, 12:59
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Your fix seems to be working. good work!, Tomasz.
Post 23 Jul 2014, 16:34
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 YouTube, Twitter.

Website powered by rwasa.