This code crashes fasm 1.67.12

Index > Compiler Internals > This code crashes fasm 1.67.12

Author

Thread

quiveror

Joined: 20 Jun 2003
Posts: 34

quiveror 26 Oct 2006, 18:24

Here it is,

Code:

format MS64 COFF

section '.data' data readable writeable align 8
caption db 'Notice',0
message db 'This is a book!',0

section '.text' code readable executable align 8
    public main
  main:
        sub     rsp,8*5
        mov     r9d,0
        lea     r8,[caption]
        lea     rdx,[message]
        mov     rcx,0
        call    [MessageBox]

        mov     ecx,eax
        call    [ExitProcess]

extrn '__imp_MessageBoxA' as MessageBox : qword
extrn '__imp_ExitProcess' as ExitProcess : qword

It tried it on WinXP and WinXP 64-bit, the newest just crashes but the 1.67.7 compiles fine though.

26 Oct 2006, 18:24

Tomasz Grysztar

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

Tomasz Grysztar 26 Oct 2006, 19:50

Fixed.

26 Oct 2006, 19:50

quiveror

Joined: 20 Jun 2003
Posts: 34

quiveror 27 Oct 2006, 08:05

No more crashes, but the OBJ failed to link anyway.
Here's the command line

Code:

link PE64DEMO.obj /FIXED:NO /subsystem:windows /entry:main /defaultlib:kernel32.lib /defaultlib:user32.lib

and error message

Code:

Microsoft (R) Incremental Linker Version 8.00.40310.39
Copyright (C) Microsoft Corporation.  All rights reserved.

PE64DEMO.obj : error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
PE64DEMO.obj : error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
PE64DEMO.obj : error LNK2017: 'ADDR32' relocation to '__imp_MessageBoxA' invalid without /LARGEADDRESSAWARE:NO
PE64DEMO.obj : error LNK2017: 'ADDR32' relocation to '__imp_ExitProcess' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors

The obj generated by fasm 1.67.7 doesn't have this problem. I also try to link without /FIXED:NO. It linked OK but run incorrectly. As I remember, the api call in 1.67.7 is RIP relative, not ADDR32 relocation.

27 Oct 2006, 08:05

Tomasz Grysztar

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

Tomasz Grysztar 27 Oct 2006, 20:51

Please try now (re-download).

27 Oct 2006, 20:51

quiveror

Joined: 20 Jun 2003
Posts: 34

quiveror 28 Oct 2006, 18:02

Works now, thank you very much Very Happy

There're 3 more little points I'd like to make here, please be patient with me.
1.

Code:

mov qword [rax],main

fasm doesn't allow the above to compile. I think it is safe to compile this (to 48h,c7h,0h,ADDR32 reloc). As there exists ADDR32, linker will have to make sure that the whole image lies entirely within the low 2GB, so sign extension shouldn't occur.
2.
fasm fails to insert 67h prefix for the following code.

Code:

mov rbx,[dword 0]

Code:

lea rax,[dword -80000000h]    ; 67h,48h,8Dh,04h,50h,00h,00h,00h,80h

the above code will leave rax = 80000000h. I suppose that
lea rax,[qword -80000000h] should produce 48h,8Dh,04h,50h,00h,00h,00h,80h
so that rax would be 0ffffffff80000000h but fasm gives me error message instead.

Regard,

28 Oct 2006, 18:02

Tomasz Grysztar

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

Tomasz Grysztar 28 Oct 2006, 19:47

1. This is a kind of bug, I'm going to fix it.

2/3. The difference between having this opcode with 67h prefix is that one does sign-extension and one does not. For the [0] address the result is the same whether you use the sign-extension or zero-extension, and thus fasm chooses the shorter instruction of the two possibilities (without 67h). If you used the address like [dword 80000000h], fasm would be forced to put the 67h there, otherwise it optimizes to shorter form.
As for the [qword xxx] form, it forces use of the full 64-bit immediate, which is not possible in this case (works only with "mov eax,[qword xxx]" etc.).

28 Oct 2006, 19:47

quiveror

Joined: 20 Jun 2003
Posts: 34

quiveror 30 Oct 2006, 17:57

Tomasz Grysztar wrote:

The difference between having this opcode with 67h prefix is that one does sign-extension and one does not. For the [0] address the result is the same whether you use the sign-extension or zero-extension, and thus fasm chooses the shorter instruction of the two possibilities (without 67h). If you used the address like [dword 80000000h], fasm would be forced to put the 67h there, otherwise it optimizes to shorter form.

Wow, this kind of optimization is sophisticated (and also tricky) indeed. However, The code

Code:

use32
mov eax,[0]

is compiled to A1h,0,0,0,0 (5 byte). I wonder why fasm doesn't produce the shorter form like 67h,A1h,0,0 (4 byte) or I probably miss something again. Sad

Regard,

30 Oct 2006, 17:57

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 30 Oct 2006, 19:06

i think this was mentioned somewhere. 32bit instructions doesn't get optimized to 16bit.

30 Oct 2006, 19:06

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 30 Oct 2006, 21:31

quiveror wrote:

Wow, this kind of optimization is sophisticated (and also tricky) indeed. However, The code
Code:
use32
mov eax,[0]
    
is compiled to A1h,0,0,0,0 (5 byte). I wonder why fasm doesn't produce the shorter form like 67h,A1h,0,0 (4 byte) or I probably miss something again.

Regard,

use32 "force the assembler to generate 32-bit code" (quote from the documentation). That is kind of vague definition, but it most probably means default 32-bit operand size and 32-bit address size. Therefore, you can't expect such 16-bit address size to be generated.

30 Oct 2006, 21:31

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 30 Oct 2006, 21:39

If I remember right some processors executes slower when there is such prefixes so I think that fasm should use that thick only when the programmer uses "mov eax, [word 0]" under a use32 block

30 Oct 2006, 21:39

Tomasz Grysztar

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

Tomasz Grysztar 01 Nov 2006, 18:17

LocoDelAssembly wrote:

If I remember right some processors executes slower when there is such prefixes so I think that fasm should use that thick only when the programmer uses "mov eax, [word 0]" under a use32 block

Yes, that's how it is.

01 Nov 2006, 18:17

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 01 Nov 2006, 18:44

Both things or just the "mov eax, [word 0]" part?

01 Nov 2006, 18:44

Tomasz Grysztar

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

Tomasz Grysztar 02 Nov 2006, 20:18

Everything you have said there. Wink

02 Nov 2006, 20:18

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 02 Nov 2006, 22:50

Nice

Thanks!

02 Nov 2006, 22:50

< 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