[Bug gas/24546] New: x86-64 far jump/call encoding issues

[andrew.cooper3 at citrix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24546

Bug ID: 24546
   Summary: x86-64 far jump/call encoding issues
   Product: binutils
   Version: 2.32
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: andrew.cooper3 at citrix dot com
  Target Milestone: ---

I have some problems when trying to encode the 64bit forms of far call/jump. 
Like all other far operations in 64bit, lcall/ljmp default to a 32bit operand,
and require a rex64 to promote the instruction to having a 64bit operand
(specifically, it changes these instructions between having a 6 byte operand
and a 10 byte operand).

$ cat far-jmps.S
.code64
code64:
lcalll *(%rsp)
rex64 lcall *(%rsp)

ljmpl *(%rsp)
rex64 ljmp *(%rsp)

lretl
lretq

This version of the file assembles correct:

$ /local/bin/bin-2.32/bin/as far-jmps.S -o far-jmps.o
$

However, when substituting the rex64 prefix for an l or q suffix, assembly
fails with:

$ /local/bin/bin-2.32/bin/as far-jmps.S -o far-jmps.o
far-jmps.S: Assembler messages:
far-jmps.S:4: Error: invalid instruction suffix for `lcall'
far-jmps.S:7: Error: invalid instruction suffix for `ljmp'

Furthermore (or possibly relatedly), objdump doesn't disassemble the
instruction in an expected manner:

$ /local/bin/bin-2.32/bin/objdump -d far-jmps.o

far-jmps.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:ff 1c 24 lcall  *(%rsp)
   3:48 ff 1c 24  rex.W lcall *(%rsp)
   7:ff 2c 24 ljmp   *(%rsp)
   a:48 ff 2c 24  rex.W ljmp *(%rsp)
   e:cb   lret  
   f:48 cblretq

The rex.W prefix printed is an accurate representation of the encoding, but an
l or q suffix would be the consistent way of rendering the instructions.

Observe that throughout all of this, lret and lretq do assemble and disassemble
in the expected manner (as do iretl and iretq which I omitted from the
example.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/24546] x86-64 far jump/call encoding issues

[andrew.cooper3 at citrix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24546

--- Comment #2 from Andrew Cooper  ---
Yes.  That works on all 64bit capable processors.

The encoding which isn't supported in 64bit mode is the ptr:16:{16,32,64}
encoding, which stores the segment and offset as immediate data operands in the
instruction.

~Andrew

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/24546] x86-64 far jump/call encoding issues

[andrew.cooper3 at citrix dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24546

--- Comment #4 from Andrew Cooper  ---
(In reply to H.J. Lu from comment #3)
> AMD64 manual says:
> 
> CALL FAR pntr16:16 9A cd Far call direct, with the target specified by a far
> pointer
> contained in the instruction. (Invalid in 64-bit mode.)
> CALL FAR pntr16:32 9A cp Far call direct, with the target specified by a far
> pointer
> contained in the instruction. (Invalid in 64-bit mode.)
> CALL FAR mem16:16 FF /3 Far call indirect, with the target specified by a
> far pointer
> in memory.
> CALL FAR mem16:32 FF /3 Far call indirect, with the target specified by a
> far pointer
> in memory.

After some experimentation, it turns out that it really is only Intel
processors which implement the mem16:64 form.  AMD processors ignore the REX
prefix and use mem16:32 form, even when REX-encoded.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils