Mac OS x under 64-bit assembly differs from Linux under 64-bit compilation

1 First system call number greatly different, MAC64 and linux32 system call number is also different (although the local may have the same)

2 MAC64 system call number in:

/usr/include/sys/syscall.h

Can be found, but the call when its value to add 0x2000000, you can write a macro processing:

%define mk64 0x2000000+

Use the following methods:

1      ;exit NOmov rdi,0           ;error_codesyscall

3 If the assembly is to be linked to the C library under MAC64, all extern symbol names should be underlined, including the entry point main:

extern _strerrorextern _printfglobal _main_main:

The underscore before the symbol must be removed when linux64 and C libraries are linked.

4 Pie in Mac (ref.: HTTP://BLOG.CSDN.NET/MYDO/ARTICLE/DETAILS/44906109), which warns you when using absolute addresses directly, you must use a relative address if you want to remove a warning:

;movrbx,addr;上一条指令要换成下一条learbx,[rel addr]movrsi,[rbx]

5 MAC64 does not allow the value to be assigned to the 32-bit absolute address, such as the following command error:

mov[addr],rax

You need to force the Declaration as a 64-bit address or instead use a relative address:

mov[qword addr],rax    ;okmov[rel addr],rax      ;oktoo

However, there is no such restriction under linux64.

6 MAC64 and linux64 are different from the C library wrapper of the system call, especially when the return value of the system call is processed, such as Mmap call, linux64 C library does not seem to check the parameters, but the syscall itself checks, and MAC64 checks the parameters before the call, if the parameters are wrong, There is no system call at all, set errno directly, and then return. Take mmap For example, if you set a breakpoint on the Mmap C library function, after the N-fast_syscall_stub:

->  0x7fff8c4fc3b5 <+277>: callq  0x7fff8c4fd9e0            ; _dyld_fast_stub_entry(voidlong)

To enter a breakpoint, so to set a conditional breakpoint on fast_syscall_stub, ignoring the previous n captures (I tested the program or slightly earlier 28 times), and then goes into the mmap function in the kernel dynamic library:

Libsystem_kernel.Dylib`mmap: -  0X7fff8ad05a96 <+0:Pushq  %RBP    0X7fff8ad05a97 <+1:movq   %RSP,%RBP    0x7fff8ad05a9a <+4:Pushq  %r15    0x7fff8ad05a9c <+6:Pushq  %r14    0x7fff8ad05a9e <+8:Pushq  %r12    0X7FFF8AD05AA0 <+Ten:Pushq  %RBX    0X7fff8ad05aa1 <+ One:MOVL   %r8d,%r15d    0X7FFF8AD05AA4 <+ -:movq   %rsi,%r14

The parameters of the incoming mmap are checked, and if a parameter error is found, the real __mmap function is not called, but the error code is set and the corresponding C library error handler is skipped according to the different error types:

<+123>: movl   $0x16, %edi    <+128>: callq  0x7fff8ad03c53            ; cerror_nocancel

Here is the disassembly of the Cerror_nocancel function:

Libsystem_kernel.dylib ' cerror_nocancel:-> 0x7fff8ad03c53<+0>: Movl%edi, -0x14a629d9 (%rip); errno 0x7fff8ad03c59<+6>: Movq%gs:0x8,%rax 0x7fff8ad03c62<+15>: Testq%rax,%rax 0x7fff8ad03c65<+18>: JE 0x7fff8ad03c69;<+22>0x7fff8ad03c67<+20>: Movl%edi, (%rax) 0x7fff8ad03c69<+22>: Movq $-0x1,%rax 0x7fff8ad03c70<+29>: Movq $-0x1,%rdx 0x7fff8ad03c77<+36>: RETQ

And the most critical point is that it seems that MAC64 directly returns the system call error code through RAX, rather than the complement of the error code returned as linux64. So the post linux64 assembly calls Mmap example (post link: http://blog.csdn.net/mydo/article/details/45007989), the code after Syscall return must be rewritten as follows:

    ;syscallfor mmap    syscall    cmp rax,0xfff    next    push rax    mov [rel errno],rax    pop rax    or rax,-1

7 Think of so many different points for the time being to be continued

Mac OS x under 64-bit assembly differs from Linux under 64-bit compilation