1

In x86_64 (assembling with nasm on Linux) my intuition tells me that rax would have the same contents after both (1) and (2).

push qword 11               ; (1) Works!
pop rax

;mov rax, qword 11          ; (2) Doesn't Work!

But (1) works just fine and (2) makes my program segfault. What is going on here?

Dylan Kirkby
  • 1,427
  • 11
  • 19
  • 1
    What about simply `mov rax, 11`? – Alexey Frunze Dec 22 '15 at 08:39
  • Have tried that too - same problem. – Dylan Kirkby Dec 22 '15 at 08:41
  • Well, NASM v 2.10 (Mar 2012) seems to assemble this into `mov eax, 11`, despite there being `bits 64` before it. However, YASM v 1.3.0 (Aug 2014) does assemble it correctly. Check out a newer version of NASM or try YASM instead. – Alexey Frunze Dec 22 '15 at 08:48
  • 4
    @AlexeyFrunze: `mov eax, 11` is what you want anyway, unless you're going to patch the binary with a constant that doesn't have the upper 32bits zeroed. Any write to a 32bit register zeros the upper 32, so `mov r/m64, imm32` (with a sign-extended imm32), or worse `mov r64, imm64` just waste insn bytes if your constant is `11`. NASM knows that, and chooses the shorter encoding (`mov r32, imm32` with a one-byte opcode that includes 3 bits for the dest register.) – Peter Cordes Dec 22 '15 at 09:29
  • @PeterCordes Forgot that, thanks for reminding! `mov rax, 0x1122334455667788` assembles into a 64-bit instruction. – Alexey Frunze Dec 22 '15 at 10:01

1 Answers1

5

push imm8 / pop is a compact way (3 bytes) to put a small integer in a register. Inefficient but exactly the same effect as mov eax,11 or mov rax, strict qword 11. Tips for golfing in x86/x64 machine code

The net result should be the same, except for leaving an 11 in stack space. They of course have different machine code, so if this is shellcode then the mov rax, 11 version include some 00 bytes which would terminate a strcpy or similar buffer overflow.

Note that NASM optimizes mov rax, 11 to mov eax, 11 because it's shorter and has exactly the same effect on the architectural state (registers values and memory, other than RIP of course since it's a shorter instruction.)

If you wanted to patch the binary later with different constants, or if you were aiming for code alignment, you might use an override strict qword 11 to force the instruction to be encoded as mov r64, imm64, the REX.W version of mov eax, 11.

YASM doesn't do code-size optimizations that change the operand-size attribute of an instruction, but NASM by default does.

mov rax, qword 11 does not force it, it mostly just sets the size of that operand, not the encoding. e.g. mov [rdi], qword 11 is an unconventional way to write mov qword [rdi], 11, where a size specifier is necessary somewhere because neither operand is a register that implies a size.

When I first posted this answer, I didn't test mov rax, strict qword 11. See also re: the 3 ways a mov of an immediate 11 into a register could be encoded which do show syntax and machine code for that:

; test-encoding.asm
    ...
    mov  eax, 11
    mov  rax, qword 11

    push qword 11   ; yasm rejects this with "invalid size for operand 1"
                    ; probably because there is no  push imm64  encoding
    pop rax

    ; push  dword [rsi]  ; no such instruction
    push  word [rsi]

nasm -felf64 test-encoding.asm
objconv -fyasm  test-encoding.o /dev/stdout

    mov     eax, 11                                 ; 0042 _ B8, 0000000B
    mov     eax, 11                                 ; 0047 _ B8, 0000000B
    push    11                                      ; 004C _ 6A, 0B
    pop     rax                                     ; 004E _ 58

objconv is Agner Fog's very nice disassembler. See the wiki for links. objdump -Mintel -d works, too, but doesn't have helpful comments about potential problems.

In 64bit mode, the default operand size for push is a qword. So the push imm8 sign-extended-constant encoding only takes two bytes.

So the push/pop encoding is shorter. If the rest of your code is buggy, possibly there's a problem that only manifests with different code alignment, or different padding?

Intel's manual says that the operand size can be overridden with a REX.W prefix or the operand-size prefix (66H), but that's not actually true. REX.W=0 can't change the operand-size to 32-bit, the operand-size of push/pop is 64-bit by default in 64-bit mode (and REX prefixes aren't available in other modes). So REX.W=1 isn't overriding it.

In 64-bit mode, the only 2 sizes for push/pop are 16 and 64-bit. (And in other modes, 16 or 32-bit).
The 2 sizes for the immediate are sign-extended 8-bit or 32-bit. (Or 16-bit for 16-bit operand-size.)

NASM, YASM, and GNU as all correctly refuse to assemble push dword [rsi] or pushl (%rsi). Using db 0x40 to manually insert a REX.W=0 prefix ahead of push qword [rsi] makes disassemblers choke on it.

Actually running push rdx on real hardware, with REX.W=0 (db 0x40) or REX.W=1 (db 0x48) gives identical results: a 64-bit push of the full register, decrementing rsp by 8. (Tested on Sandybridge when I wrote this answer, and later also on Skylake or Core 2, I forget which I was using when answering How many bytes does the push instruction push onto the stack when I don't specify the operand size? which covers the same details.)

This wouldn't be the first time the Intel manual is wrong. :/ The table of valid encodings in the same entry in the instruction-set reference does confirm that push r32 and push r/m32 are Not Encodeable in 64-bit mode, only compat / legacy modes, but the phrasing of the description section saying that a REX.W can override the operand-size is definitely wrong.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • Thank you for the detailed answer and pointer to some good tools @Peter! When I get time, I'll play around with the different assemblers and see what opcodes result. I'll mark this as accepted once I figure out what's going on in my code! – Dylan Kirkby Dec 23 '15 at 20:37