x64 nasm: pushing memory addresses onto the stack & call function

Question

I'm pretty new to x64-assembly on the Mac, so I'm getting confused porting some 32-bit code in 64-bit.
The program should simply print out a message via the printf function from the C standart library.
I've started with this code:

section .data
    msg db 'This is a test', 10, 0    ; something stupid here

section .text
    global _main
    extern _printf

_main:
    push    rbp
    mov     rbp, rsp       

    push    msg
    call    _printf

    mov     rsp, rbp
    pop     rbp
    ret

Compiling it with nasm this way:

$ nasm -f macho64 main.s

Returned following error:

main.s:12: error: Mach-O 64-bit format does not support 32-bit absolute addresses

I've tried to fix that problem byte changing the code to this:

section .data
    msg db 'This is a test', 10, 0    ; something stupid here

section .text
    global _main
    extern _printf

_main:
    push    rbp
    mov     rbp, rsp       

    mov     rax, msg    ; shouldn't rax now contain the address of msg?
    push    rax         ; push the address
    call    _printf

    mov     rsp, rbp
    pop     rbp
    ret

It compiled fine with the nasm command above but now there is a warning while compiling the object file with gcc to actual program:

$ gcc main.o
ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not
allowed in code signed PIE, but used in _main from main.o. To fix this warning,
don't compile with -mdynamic-no-pic or link with -Wl,-no_pie

Since it's a warning not an error I've executed the a.out file:

$ ./a.out
Segmentation fault: 11

Hope anyone knows what I'm doing wrong.

score 9 · Accepted Answer · edited May 21 '19 at 17:03

The 64-bit OS X ABI complies at large to the System V ABI - AMD64 Architecture Processor Supplement. Its code model is very similar to the Small position independent code model (PIC) with the differences explained here. In that code model all local and small data is accessed directly using RIP-relative addressing. As noted in the comments by Z boson, the image base for 64-bit Mach-O executables is beyond the first 4 GiB of the virtual address space, therefore push msg is not only an invalid way to put the address of msg on the stack, but it is also an impossible one since PUSH does not support 64-bit immediate values. The code should rather look similar to:

   ; this is what you *would* do for later args on the stack
lea   rax, [rel msg]  ; RIP-relative addressing
push  rax

But in that particular case one needs not push the value on the stack at all. The 64-bit calling convention mandates that the fist 6 integer/pointer arguments are passed in registers RDI, RSI, RDX, RCX, R8, and R9, exactly in that order. The first 8 floating-point or vector arguments go into XMM0, XMM1, ..., XMM7. Only after all the available registers are used or there are arguments that cannot fit in any of those registers (e.g. a 80-bit long double value) the stack is used. 64-bit immediate pushes are performed using MOV (the QWORD variant) and not PUSH. Simple return values are passed back in the RAX register. The caller must also provide stack space for the callee to save some of the registers.

printf is a special function because it takes variable number of arguments. When calling such functions AL (the low byte of RAX) should be set to the number of floating-point arguments, passed in the vector registers. Also note that RIP-relative addressing is preferred for data that lies within 2 GiB of the code.

Here is how gcc translates printf("This is a test\n"); into assembly on OS X:

    xorl    %eax, %eax             # (1)
    leaq    L_.str(%rip), %rdi     # (2)
    callq   _printf                # (3)

L_.str:
    .asciz   "This is a test\n"

(this is AT&T style assembly, source is left, destination is right, register names are prefixed with %, data width is encoded as a suffix to the instruction name)

At (1) zero is put into AL (by zeroing the whole RAX which avoids partial-register delays) since no floating-point arguments are being passed. At (2) the address of the string is loaded in RDI. Note how the value is actually an offset from the current value of RIP. Since the assembler doesn't know what this value would be, it puts a relocation request in the object file. The linker then sees the relocation and puts the correct value at link time.

I am not a NASM guru, but I think the following code should do it:

default rel             ; make [rel msg] the default for [msg]
section .data
    msg:  db 'This is a test', 10, 0    ; something stupid here

section .text
    global _main
    extern _printf

_main:
    push    rbp                 ; re-aligns the stack by 16 before call
    mov     rbp, rsp       

    xor     eax, eax            ; al = 0 FP args in XMM regs
    lea     rdi, [rel msg]
    call    _printf

    mov     rsp, rbp
    pop     rbp
    ret

Should the function remove the parameters from the stack or should the caller remove them? (if there are any parameters on the stack) — qwertz, Oct 27 '12 at 13:13
Your answer does not really explain why NASM won't create the object file. The reason is a limitation of Mac OS X. The image base is larger than 2^32 on OS X. The OP's original code will assemble fine with elf64. [mach-o-64-bit-format-does-not-support-32-bit-absolute-addresses-nasm](https://stackoverflow.com/questions/26394359/mach-o-64-bit-format-does-not-support-32-bit-absolute-addresses-nasm/26402647#26402647) — Z boson, Oct 16 '14 at 11:15
@Zboson, hm, that Mach-O 64-bit does not support 32-bit absolute addresses is evident from the error message in the question, therefore I've probably considered it unnecessary to explain the problem further (or I was simply being lazy after a day at work - more likely) and have given directly the solution. My statement about the conformance to the SysV AMD64 ABI is not entirely correct though. I will expand the paragraph and add the corresponding references. — Hristo Iliev, Oct 16 '14 at 14:49
@HristoIliev, I deleted my answer on the other question. Your answer and mine make this question complete now so the other question is now a duplicate. — Z boson, Oct 16 '14 at 15:20
BTW, [`xor eax,eax` is the most efficient way to zero AL](https://stackoverflow.com/questions/33666617/what-is-the-best-way-to-set-a-register-to-zero-in-x86-assembly-xor-mov-or-and). And BTW, closed [Mach-O 64-bit format does not support 32-bit absolute addresses. NASM](https://stackoverflow.com/a/26402647) as a dup of this; thanks @ZBoson — Peter Cordes, May 15 '18 at 22:49

score 5 · Answer 2 · edited May 23 '17 at 12:15

No answer yet has explained why NASM reports

Mach-O 64-bit format does not support 32-bit absolute addresses

The reason NASM won't do this is explained in Agner Fog's Optimizing Assembly manual in section 3.3 Addressing modes under the subsection titled 32-bit absolute addressing in 64 bit mode he writes

32-bit absolute addresses cannot be used in Mac OS X, where addresses are above 2^32 by default.

This is not a problem on Linux or Windows. In fact I already showed this works at static-linkage-with-glibc-without-calling-main. That hello world code uses 32-bit absolute addressing with elf64 and runs fine.

@HristoIliev suggested using rip relative addressing but did not explain that 32-bit absolute addressing in Linux would work as well. In fact if you change lea rdi, [rel msg] to lea rdi, [msg] it assembles and runs fine with nasm -efl64 but fails with nasm -macho64

Like this:

section .data
    msg db 'This is a test', 10, 0    ; something stupid here

section .text
    global _main
    extern _printf

_main:
    push    rbp
    mov     rbp, rsp       

    xor     al, al
    lea     rdi, [msg]
    call    _printf

    mov     rsp, rbp
    pop     rbp
    ret

You can check that this is an absolute 32-bit address and not rip relative with objdump. However, it's important to point out that the preferred method is still rip relative addressing. Agner in the same manual writes:

There is absolutely no reason to use absolute addresses for simple memory operands. Rip- relative addresses make instructions shorter, they eliminate the need for relocation at load time, and they are safe to use in all systems.

So when would use use 32-bit absolute addresses in 64-bit mode? Static arrays is a good candidate. See the following subsection Addressing static arrays in 64 bit mode. The simple case would be e.g:

mov eax, [A+rcx*4]

where A is the absolute 32-bit address of the static array. This works fine with Linux but once again you can't do this with Mac OS X because the image base is larger than 2^32 by default. To to this on Mac OS X see example 3.11c and 3.11d in Agner's manual. In example 3.11c you could do

mov eax, [(imagerel A) + rbx + rcx*4]

Where you use the extern reference from Mach O __mh_execute_header to get the image base. In example 3.11c you use rip relative addressing and load the address like this

lea rbx, [rel A]; rel tells nasm to do [rip + A]
mov eax, [rbx + 4*rcx] ; A[i]

I simply cannot find a reliable information as to why 64-bit Mach-O binaries have their image base so high, but it seems that on x86-64 `__PAGEZERO` segment occupies the whole first 4 GiB of the VM and thus any 32-bit pointer is invalid (`__PAGEZERO` is neither readable nor writeable or executable). It's probably a cheap way to detect old program code that assumes `sizeof(int)` to be equal to `sizeof(void *)` by simply crashing the program. — Hristo Iliev, Oct 18 '14 at 00:53
[This answer](http://stackoverflow.com/a/23188634/1374437) and the comment to it indicate that my assumption is probably correct. — Hristo Iliev, Oct 18 '14 at 00:57
@HristoIliev, It looks like you figure it you out. I'm wondering what other effect this has. It means that the addressing mode [absolute 32-bit address + index] for static arrays is not possible with OS X. Evgeny Kluev's suggestion to my question https://stackoverflow.com/questions/25899395/obtaining-peak-bandwidth-on-haswell-in-the-l1-cache-only-getting-62 would be impossible with OS X. Some instructions/ports (e.g. port 7 on Haswell) only work with this simple addressing mode. Also micro-op fusion might be effected http://stackoverflow.com/questions/26046634/micro-fusion-and-addressing-modes — Z boson, Oct 18 '14 at 12:56
If you're going to use 32-bit absolute addressing for putting static addresses in registers, use `mov edi, msg` like Linux `gcc -fno-pie` will. *That's* a more widespread use of 32-bit absolute addressing than indexing static arrays. (Although it only saves code size, not instructions. But `mov reg,imm32` can run on more ports than LEA.) — Peter Cordes, May 21 '19 at 21:17

score 2 · Answer 3 · answered Oct 26 '12 at 18:11

According to the documentation for the x86 64bit instruction set http://download.intel.com/products/processor/manual/325383.pdf

PUSH only accepts 8, 16 and 32bit immediate values (64bit registers and register addressed memory blocks are allowed though).

PUSH msg

Where msg is a 64bit immediate address will not compile as you found out.

What calling convention is _printf defined as in your 64bit library?

Is it expecting the parameter on the stack or using a fast-call convention where the parameters on in registers? Because x86-64 makes more general purpose registers available the fast-call convention is used more often.

`msg` is a 32-bit address so the problem is not `PUSH`. The problem is that Mach-O does not allow 32-bit absolute addressing. — Z boson, Oct 16 '14 at 14:40

x64 nasm: pushing memory addresses onto the stack & call function

3 Answers3

Linked

Related