bug in fastcall(64-bit) macro, incomplete addressing support

Index > Macroinstructions > bug in fastcall(64-bit) macro, incomplete addressing support

Author

Thread

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 19 May 2009, 05:57

Code:

include 'win64a.inc'
use64
        fastcall blah,ecx,edx,r8,r9,dword[esp+40] ;Operand sizes do not match.
        fastcall blah,ecx,edx,r8,r9,[esp+40] ;Operand size not specified.
        fastcall blah,ecx,edx,r8,r9,dword[rsp+40] ;OK!
blah:
  ret

Seems that its using prefixes as hints, but in 64-bit mode 32-bit registers are not recommended (even forbidden on Intel compiler) and this tiny bit has been missed when writing these macros.

Shall I take the courage to fix this myself? It is not necessary that it worked, but it will give hard time to asmers coming from 32-bit world. Actually this bug surfaced with porting 32-bit code.

_________________
My updated idol Very Happy

http://www.agner.org/optimize/

Last edited by Madis731 on 19 May 2009, 08:08; edited 1 time in total

19 May 2009, 05:57

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 19 May 2009, 06:17

Madis731 wrote:

...but in 64-bit mode 32-bit registers are not recommended...

What does this mean exactly? I don't remember recommendation like this in the fastcall documentation.

19 May 2009, 06:17

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 19 May 2009, 06:50

Sorry, not the fastcall recommendation, but 64-bit addressing:

Code:

mov eax,[ebp+eax*4] ; is not recommended
mov eax,[rbp+rax*4] ; is recommended and even enforced i.e. Intel C-compiler in asm {} blocks.

19 May 2009, 06:50

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20516
Location: In your JS exploiting you and your system

revolution 19 May 2009, 06:57

That is like in Win32 doing this:

Code:

format PE GUI ...
...
MyString: "Hello cruel world!",13,10,0
...
mov ebx,MyString
mov al,[bx]
...

19 May 2009, 06:57

Madis731

Joined: 25 Sep 2003
Posts: 2139
Location: Estonia

Madis731 19 May 2009, 08:03

Code:

;proc64.inc @ 144,1
-        else if opcode = 0FFh
+        else if opcode = 0FFh | opcode = 67h

19 May 2009, 08:03

asmfan

Joined: 11 Aug 2006
Posts: 392
Location: Russian

asmfan 24 Jun 2009, 08:23

Relatively this "simple" macro for win64 calling convention - the convention itself was made with respect to ease some obvious things like constant stack pointer moving which is absent in win64 CC but this macro revert us to x32 disadvantages. despite commitiong whole stack on entry equal to uneven max arg count of leaves-function *8 if playing with stack each time API's called. Suggest removing this macro definition till or if it will count args for leaf-func to balance stack once.

24 Jun 2009, 08:23

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 24 Jun 2009, 10:36

asmfan wrote:

Relatively this "simple" macro for win64 calling convention - the convention itself was made with respect to ease some obvious things like constant stack pointer moving which is absent in win64 CC but this macro revert us to x32 disadvantages. despite commitiong whole stack on entry equal to uneven max arg count of leaves-function *8 if playing with stack each time API's called. Suggest removing this macro definition till or if it will count args for leaf-func to balance stack once.

Please read this thread: http://board.flatassembler.net/topic.php?t=4209
Perhaps you'd like to continue the discussion there.

24 Jun 2009, 10:36

< 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