NASM - The Netwide Assembler

NASM Forum => Programming with NASM => Topic started by: ironman on September 05, 2011, 07:44:59 PM

Title: Far Calls in 64-bit
Post by: ironman on September 05, 2011, 07:44:59 PM

Hello all.

I was looking at the test files, in particular far64.asm. I was experimenting with the following line:

Code: [Select]

call qword far [rax]
In particular, I tried replacing rax with an immediate:

Code: [Select]

call qword far [0x7ffff7c11ca0]
Oddly, this gives me an error:

Quote

far64.asm:5: warning: dword data exceeds bounds

But I am not using a dword. Also, I've checked to see if the warning has any bearing on the output. Indeed it does, the bytes output are incorrect. Thanks for any help.

Title: Re: Far Calls in 64-bit
Post by: Rob Neff on September 06, 2011, 01:31:29 AM

That is a known bug that we hope will be fixed by the next release.

Title: Re: Far Calls in 64-bit
Post by: Cyrill Gorcunov on September 06, 2011, 07:07:05 AM

Yeah, just ignore such warnings for a while.

Title: Re: Far Calls in 64-bit
Post by: Frank Kotler on September 06, 2011, 10:23:18 AM

Yeah, the warning is known, and should be ignored, but he says the bytes are wrong. Looks like signed 32-bit... which I think is correct... but I don't know enough 64-bit to be sure.

BTW, "call strict qword" doesn't "fix" it...

Thanks for the feedback, Matt.

Best,
Frank

Title: Re: Far Calls in 64-bit
Post by: ironman on September 07, 2011, 04:54:57 PM

I am finding that this problem extends to not just CALL instructions, but several others as well. For example, even

Code: [Select]

mov rbx,[0xaaaaaaaaaaaaaaaa]

creates incorrect bytes. This example is pulled directly from test/riprep.pl. These problems are all subverted by just moving the value of interest into a 64-bit register and then using as needed, but it is awkward to do it this way.

-Matt

Title: Re: Far Calls in 64-bit
Post by: Cyrill Gorcunov on October 16, 2011, 05:56:02 PM

In 64 bit mode the EA displacements are 4 bytes long (the parasite warning we have sometime due to sign extension is a different problem).

Title: Re: Far Calls in 64-bit
Post by: Cyrill Gorcunov on October 17, 2011, 06:52:27 PM

Ah, guys, you might be meaning moffsets (ie direct memory-offset MOVs)? If so such MOV requires qword inside square brackets.

For example

Code: [Select]

[bits 64]
mov rax, [qword 0x1111111111111111]
mov al,  [qword 0x1111111111111111]
mov eax, [qword 0x1111111111111111]


Title: Re: Far Calls in 64-bit
Post by: Cyrill Gorcunov on October 17, 2011, 06:53:39 PM

Quote from: Cyrill Gorcunov on October 17, 2011, 06:52:27 PM

Ah, guys, you might be meaning moffsets (ie direct memory-offset MOVs)? If so such MOV requires qword inside square brackets.

For example

Code: [Select]

[bits 64]
mov rax, [qword 0x1111111111111111]
mov al,  [qword 0x1111111111111111]
mov eax, [qword 0x1111111111111111]


And it operates with r/e/ax register only.

Title: Re: Far Calls in 64-bit
Post by: Cyrill Gorcunov on October 17, 2011, 07:13:28 PM

Please check out "11.2 Immediates and Displacements in 64-bit Mode" of nasm manual.
http://www.nasm.us/xdoc/2.09.10/html/nasmdo11.html#section-11.2 (http://www.nasm.us/xdoc/2.09.10/html/nasmdo11.html#section-11.2)