Assembler Error: Mach-O 64 bit does not support absolute 32 bit addresses

Question

So I\'m learning x86_64 nasm assembly on my mac for fun. After hello world and some basic arithmetic, I tried copying a slightly more advanced hello world program from this

Answer 1

I believe the problem you are facing is simple: the Mach-O format mandates relocatable code, which means that the data has to be accessed not by absolute address but by a relative address. That is, the assembler can't resolve name to a constant because it's not a constant, the data could be at any address.

Now that you know that the address of data is relative to the address of your code, see if you can make sense of the output from GCC. For example,

static unsigned global_var;
unsigned inc(void)
{
    return ++global_var;
}

_inc:
    mflr r0                                           ; Save old link register
    bcl 20,31,"L00000000001$pb"                       ; Jump
"L00000000001$pb":
    mflr r10                                          ; Get address of jump
    mtlr r0                                           ; Restore old link register
    addis r2,r10,ha16(_global_var-"L00000000001$pb")  ; Add offset to address
    lwz r3,lo16(_global_var-"L00000000001$pb")(r2)    ; Load global_var
    addi r3,r3,1                                      ; Increment global_var
    stw r3,lo16(_global_var-"L00000000001$pb")(r2)    ; Store global_var
    blr                                               ; Return

Note that this is on PowerPC, because I don't know the Mach-O ABI for x86-64. On PowerPC, you do a jump, saving the program counter, and then do arithmetic on the result. I believe something completely different happens on x86-64.

(Note: If you look at GCC's assembly output, try looking at it with -O2. I don't bother looking at -O0 because it's too verbose and more difficult to understand.)

My recommendation? Unless you are writing a compiler (and sometimes even then), write your assembly functions in one of two ways:

• Pass all necessary pointers as arguments to the function, or,
• Write the assembly as inline assembly inside a C function.

This will generally be more portable as well, since you will rely less on certain details of the ABI. But the ABI is still important! If you don't know the ABI and follow it, then you'll cause errors that are fairly difficult to detect. For instance, years ago there was a bug in LibSDL assembly code which caused libc's memcpy (also assembly) to copy the wrong data under some very specific circumstances.