Author Topic: Far Calls in 64-bit  (Read 11836 times)

Offline ironman

  • Jr. Member
  • *
  • Posts: 5
Far Calls in 64-bit
« 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.

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Far Calls in 64-bit
« Reply #1 on: September 06, 2011, 01:31:29 AM »
That is a known bug that we hope will be fixed by the next release.

Offline Cyrill Gorcunov

  • NASM Developer
  • Full Member
  • *****
  • Posts: 179
  • Country: 00
Re: Far Calls in 64-bit
« Reply #2 on: September 06, 2011, 07:07:05 AM »
Yeah, just ignore such warnings for a while.

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Far Calls in 64-bit
« Reply #3 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

« Last Edit: September 06, 2011, 10:27:30 AM by Frank Kotler »

Offline ironman

  • Jr. Member
  • *
  • Posts: 5
Re: Far Calls in 64-bit
« Reply #4 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


Offline Cyrill Gorcunov

  • NASM Developer
  • Full Member
  • *****
  • Posts: 179
  • Country: 00
Re: Far Calls in 64-bit
« Reply #5 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).

Offline Cyrill Gorcunov

  • NASM Developer
  • Full Member
  • *****
  • Posts: 179
  • Country: 00
Re: Far Calls in 64-bit
« Reply #6 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]

Offline Cyrill Gorcunov

  • NASM Developer
  • Full Member
  • *****
  • Posts: 179
  • Country: 00
Re: Far Calls in 64-bit
« Reply #7 on: October 17, 2011, 06:53:39 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.

Offline Cyrill Gorcunov

  • NASM Developer
  • Full Member
  • *****
  • Posts: 179
  • Country: 00
Re: Far Calls in 64-bit
« Reply #8 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