'symbol' relocation to 'segment' invalid without /LARGEADDRESSAWARE:NO

You are trying to build a 64-bit image with 32-bit addresses. To do this, you must:

- Use a fixed load address.
- Restrict the image to 3 GB.
- Specify /largeaddressaware:no.

mov eax, some_label    

lea eax, [some_label]    

macro mov dest, src
{
    if src eqtype mylabel
        lea dest, [src]
    else
        mov dest, src
    end if
}
mylabel:    

A$M
As long as you compile that to an obj file, the labels are relocatable and hence do not have absolute values (e.g., you cannot divide such a label by a constant). Therefore relativeto is your friend here. First make sure the argument is of an expression type via eqtype, then make sure that expression has a non-absolute value by comparing it with relativeto 0. This will not catch expressions with registers though, so you also may choose to compare relativeto some_label_with_same_base_as_needed, but this wouldn't be necessary for mov. Things may get different with push, if the code you compile employs its dirty features.

macro mov dest, src
{
        if src eq esp
                mov dest, ESP    ; This is from modes.inc. I'm not sure what it does but I'm keeping it
        else if src eqtype 0 & ~src relativeto 0
                lea r8d, [src]
                mov dest, r8d
        else
                mov dest, src
        end if
}    

macro loop dest
{
        dec ecx
        jnz dest
}    

use64
org $100000000
mov eax,$$
lea eax,[$$]    

org $10000
jmp $    

A$M
My ability to think is very limited at the afterwork hours, but it seems you are pointing out a bug in fasm:

Code:

use64
org $100000000
mov eax,$$
lea eax,[$$]    

None of the above two instructions should compile, but the overflow is caught for mov only.

use64
org 0x10000

        dq asm_test    ; This is how I get the public symbols from C++
        dq val1
        dq val2

asm_test:
        add rsp, 8*5

        mov rax, val1
        mov qword[rax], 25

        lea eax, [val2]
        mov qword[eax], 50

        sub rsp, 8*5
        ret

        val1 dq 0
        val2 dq 0    

OK. I thought a few more times about that, and this is probably not a bug, as fasm has never been conservative enough to expect an explicit "cast" with things like lea ax,[eax]. In fact, such a cast already has a different effect assigned to it, which is forcing a longer immediate encoding.

The problem with the above code is that rip in the address expression became implicit similarly to how ip has always been implicit in control transfer instructions with ip-relative addressing. So I see a bit of an inconsistency in that the overflow check is performed in the following code, but not in the code above.

Code:

org $10000
jmp $