flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > This code crashes fasm 1.67.12

Author
Thread Post new topic Reply to topic
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror
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.
Post 26 Oct 2006, 18:24
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Fixed.
Post 26 Oct 2006, 19:50
View user's profile Send private message Visit poster's website Reply with quote
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror
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.
Post 27 Oct 2006, 08:05
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Please try now (re-download).
Post 27 Oct 2006, 20:51
View user's profile Send private message Visit poster's website Reply with quote
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror
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]    

3.
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,
Post 28 Oct 2006, 18:02
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.).
Post 28 Oct 2006, 19:47
View user's profile Send private message Visit poster's website Reply with quote
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror
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,
Post 30 Oct 2006, 17:57
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
i think this was mentioned somewhere. 32bit instructions doesn't get optimized to 16bit.
Post 30 Oct 2006, 19:06
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
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. Sad

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.
Post 30 Oct 2006, 21:31
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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
Post 30 Oct 2006, 21:39
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 01 Nov 2006, 18:17
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Both things or just the "mov eax, [word 0]" part?
Post 01 Nov 2006, 18:44
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
Everything you have said there. Wink
Post 02 Nov 2006, 20:18
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Nice Very Happy

Thanks!
Post 02 Nov 2006, 22:50
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 GitHub, YouTube, Twitter.

Website powered by rwasa.