Related Projects > NASMX

BUG of "USES MARCO"

<< < (2/3) > >>

Frank Kotler:
Okay, thanks for checking it, Encryptor256. I'd test it myself, but I haven't got NASMX installed (properly) at this point...

Best,
Frank

Rob Neff:
Logically, the USES macro moves the contents of registers to the procedure stack.  We defer updating the stack offset until after the LOCALS macro since additional local procedure variables may be defined via LOCAL until we reach ENDLOCALS.  That's the main reason why USES must come before LOCALS.

When specifying LOCALS NONE we should be simply offsetting the stack pointer to the correct aligned offset of total registers saved.

Finally, during ENDPROC, we unwind the stack and restore any previously saved registers.  This scheme is used identically between x32 and x64 and accounts for the various calling conventions supported.

I'm not sure why you're seeing the insertion of add esp, 0x10 ( or, in encryptor's case, the add rsp, byte +20 )  line there.  I'll investigate when I get some free time.

encryptor256:
Okay, here is one more x32 test, notify "uses ebx":

Compile code with "nasm.exe -f win32 test.asm -o test.obj":

--- Code: ---bits 32
%include "nasmx.inc"

proc testProc,dword x,dword y
   uses ebx
   locals none
   mov eax,1
endproc

--- End code ---

NDisasm with "ndisasm -b 32 test.obj":

--- Code: ---0000003C  55                push ebp
0000003D  89E5              mov ebp,esp
0000003F  895DFC            mov [ebp-0x4],ebx
00000042  83EC08            sub esp,byte +0x8
00000045  B801000000        mov eax,0x1
0000004A  83C404            add esp,byte +0x4
0000004D  5B                pop ebx
0000004E  89EC              mov esp,ebp
00000050  5D                pop ebp
00000051  C20800            ret 0x8

--- End code ---

Here is one more x64 test, notify "uses rbx":

Compile code with "nasm.exe -f win32 test.asm -o test.obj":

--- Code: ---bits 64
%include "nasmx.inc"

proc testProc,dword x,dword y
   uses rbx
   locals none
   mov rax,1
endproc

--- End code ---

NDisasm with "ndisasm -b 64 test.obj":

--- Code: ---0000003C  55                push rbp
0000003D  4889E5            mov rbp,rsp
00000040  48895DF8          mov [rbp-0x8],rbx
00000044  4883EC10          sub rsp,byte +0x10
00000048  B801000000        mov eax,0x1
0000004D  4883C408          add rsp,byte +0x8
00000051  5B                pop rbx
00000052  4889EC            mov rsp,rbp
00000055  5D                pop rbp
00000056  C3                ret

--- End code ---

Offtopic:

Path: "nasmx-1.3\demos\win32\DEMO17"

DEMO17 - Bitmaps and Timer example

Demo17 source code claims, that,
it want's to be Demo16,
but Demo16 already exists,
partial data section content of demo17.asm:


--- Code: ---...
[section .data]

    szTitle:               declare(NASMX_TCHAR) NASMX_TEXT("Demo 16 - WinFloor"), 0x0
...

--- End code ---

* Single byte change in window title is required.

Bye!

Rob Neff:

--- Quote from: encryptor256 on February 24, 2014, 05:59:56 PM ---NDisasm with "ndisasm -b 64 test.obj":

--- Code: ---0000003C  55                push rbp
0000003D  4889E5            mov rbp,rsp
00000040  48895DF8          mov [rbp-0x8],rbx
00000044  4883EC10          sub rsp,byte +0x10
00000048  B801000000        mov eax,0x1
0000004D  4883C408          add rsp,byte +0x8
00000051  5B                pop rbx
00000052  4889EC            mov rsp,rbp
00000055  5D                pop rbp
00000056  C3                ret

--- End code ---

--- End quote ---

hmmmm...that's the way it's supposed to work.  By keeping the stack aligned to a 16-byte boundary in the prologue any future INVOKE calls within the procedure can happen without penalty.  During the epilogue it correctly adjusts the stack offset by first adding 0x8 ( ie: we allocated an additional 8 bytes in the prologue due to only storing one register ) prior to popping off the register(s) saved.

In addition to investigating the original issue this also gives me an idea that the logic can be optimized further when saving registers if we encounter a LOCALS NONE statement.  We can eliminate the "add rsp, 8" statement in the epilogue if we pre-align saved registers on the alignment boundary and just start popping.  So maybe I can kill two birds with one stone here!  8)


--- Quote from: encryptor256 on February 24, 2014, 05:59:56 PM ---
Path: "nasmx-1.3\demos\win32\DEMO17"

DEMO17 - Bitmaps and Timer example

Demo17 source code claims, that,
it want's to be Demo16,
but Demo16 already exists,
partial data section content of demo17.asm:


--- Code: ---...
[section .data]

    szTitle:               declare(NASMX_TCHAR) NASMX_TEXT("Demo 16 - WinFloor"), 0x0
...

--- End code ---

* Single byte change in window title is required.

Bye!

--- End quote ---

Well, at least that one is easy to fix!  :D

Rob Neff:
OK, made a bug fix to the USES macro to prevent the issue.
If you want to test it you can grab an entire snapshot or just download nasmx.inc

Navigation

[0] Message Index

[#] Next page

[*] Previous page