Another information ;)

[MaxMax]

I have compiled the file  test\riprel2.asm and I got this code.

Code: [Select]

riprel2.asm

;Testname=unoptimized; Arguments=-fbin -oriprel2.bin -O0; Files=stdout stderr riprel.bin
;Testname=optimized;   Arguments=-fbin -oriprel2.bin -Ox; Files=stdout stderr riprel.bin

bits 64

default rel
mov dword [foo],12345678h
mov qword [foo],12345678h
mov [foo],rax
mov dword [foo],12345678h
foo:

decompile riprel2.bin with nDisAsm

00000000  C7051C00000078563412      mov dword [rel 0x26],0x12345678
0000000A  48C7051100000078563412    mov qword [rel 0x26],0x12345678
00000015  4889050A000000            mov [rel 0x26],rax
0000001C  C7050000000078563412      mov dword [rel 0x26],0x12345678
I rebuilt the resulting code but I got different code.

Code: [Select]

recompile

bits 64
mov dword [rel 0x26],0x12345678
mov qword [rel 0x26],0x12345678
mov [rel 0x26],rax
mov dword [rel 0x26],0x12345678

decompile riprel2.bin with nDisAsm 
         
00000000  C704252600000078563412    mov dword [0x26],0x12345678
0000000B  48C704252600000078563412  mov qword [0x26],0x12345678
00000017  4889042526000000          mov [0x26],rax
0000001F  C704252600000078563412    mov dword [0x26],0x12345678
Why?

thanks a lot

Sorry for my bad English

[Frank Kotler]

Well... you're assembling two different sources. Does Nasm not warn you, on your second example, that an absolute address can not be RIP-relative? So... they're different. Perhaps Nasm should error-out entirely on this, since it can't do what you ask, but... it does what it does...

Best,
Frank

[MaxMax]

thanks,
ok default is absolute
But

mov qword [rel 0x26],0x12345678     bytecode > 48C7051100000078563412

and

mov qword [rel 0x26],0x12345678      bytecode > 48C704252600000078563412

Are different?

Different is not recognize segment part( Foo: in first exsample replaced with value and seg on second pass ) but they are equal

I do not think a logical 100% correct

thanks

[Frank Kotler]

I'm not very familiar with 64-bit code, so I could be confused (it's been happening a lot lately!).

If I understand correctly, "[rel 0x26]" is in fact invalid code. Rather than raise an error (and stop), Nasm chooses to emit a warning and generate an absolute addressing mode (behind our back?). I don't know why. If your point is that this should be an error, I guess I agree. As you can see, 0x26 is no longer the correct address (if "foo" still existed, it would be at 0x2A). If we ran this code, we'd be scribbling on that last operand!

Different is not recognize segment part( Foo: in first exsample replaced with value and seg on second pass ) but they are equal

I don't see a "segment part" involved in either case. One of us is confused here, and it may not be me this time. As I understand the 64-bit world, we're forced into "flat memory model" with the exception of "fs:" and "gs:". Nasm will generate the other segment overrides if we say so, but warns that they will be  ignored. At least it does what we say...

Since you mention "passes"... If we put "v" at the end of the "-O" switch, Nasm will burp up how many passes it actually took. Turns out that if we say "rel", Nasm takes 3 passes, even if we specify "-O0v". If we leave it at "abs", only 2 passes. I didn't know that.

If I misunderstand what you're "getting at" here, MaxMax - try me again...

Best,
Frank