NASM - The Netwide Assembler
NASM Forum => Using NASM => Topic started by: MaxMax on April 14, 2015, 03:48:51 PM
-
I have compiled the file test\riprel2.asm and I got this code.
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.
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
-
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
-
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
-
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