[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:

0000000000000000 <code64>:
   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 cb                    lretq

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.