Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.
1 =============================================== 2 Power Architecture 64-bit Linux system call ABI 3 =============================================== 4 5 syscall 6 ======= 7 8 syscall calling sequence[*] matches the Power Architecture 64-bit ELF ABI 9 specification C function calling sequence, including register preservation 10 rules, with the following differences. 11 12 [*] Some syscalls (typically low-level management functions) may have 13 different calling sequences (e.g., rt_sigreturn). 14 15 Parameters and return value 16 --------------------------- 17 The system call number is specified in r0. 18 19 There is a maximum of 6 integer parameters to a syscall, passed in r3-r8. 20 21 Both a return value and a return error code are returned. cr0.SO is the return 22 error code, and r3 is the return value or error code. When cr0.SO is clear, 23 the syscall succeeded and r3 is the return value. When cr0.SO is set, the 24 syscall failed and r3 is the error code that generally corresponds to errno. 25 26 Stack 27 ----- 28 System calls do not modify the caller's stack frame. For example, the caller's 29 stack frame LR and CR save fields are not used. 30 31 Register preservation rules 32 --------------------------- 33 Register preservation rules match the ELF ABI calling sequence with the 34 following differences: 35 36 r0: Volatile. (System call number.) 37 r3: Volatile. (Parameter 1, and return value.) 38 r4-r8: Volatile. (Parameters 2-6.) 39 cr0: Volatile (cr0.SO is the return error condition) 40 cr1, cr5-7: Nonvolatile. 41 lr: Nonvolatile. 42 43 All floating point and vector data registers as well as control and status 44 registers are nonvolatile. 45 46 Invocation 47 ---------- 48 The syscall is performed with the sc instruction, and returns with execution 49 continuing at the instruction following the sc instruction. 50 51 Transactional Memory 52 -------------------- 53 Syscall behavior can change if the processor is in transactional or suspended 54 transaction state, and the syscall can affect the behavior of the transaction. 55 56 If the processor is in suspended state when a syscall is made, the syscall 57 will be performed as normal, and will return as normal. The syscall will be 58 performed in suspended state, so its side effects will be persistent according 59 to the usual transactional memory semantics. A syscall may or may not result 60 in the transaction being doomed by hardware. 61 62 If the processor is in transactional state when a syscall is made, then the 63 behavior depends on the presence of PPC_FEATURE2_HTM_NOSC in the AT_HWCAP2 ELF 64 auxiliary vector. 65 66 - If present, which is the case for newer kernels, then the syscall will not 67 be performed and the transaction will be doomed by the kernel with the 68 failure code TM_CAUSE_SYSCALL | TM_CAUSE_PERSISTENT in the TEXASR SPR. 69 70 - If not present (older kernels), then the kernel will suspend the 71 transactional state and the syscall will proceed as in the case of a 72 suspended state syscall, and will resume the transactional state before 73 returning to the caller. This case is not well defined or supported, so this 74 behavior should not be relied upon. 75 76 77 vsyscall 78 ======== 79 80 vsyscall calling sequence matches the syscall calling sequence, with the 81 following differences. Some vsyscalls may have different calling sequences. 82 83 Parameters and return value 84 --------------------------- 85 r0 is not used as an input. The vsyscall is selected by its address. 86 87 Stack 88 ----- 89 The vsyscall may or may not use the caller's stack frame save areas. 90 91 Register preservation rules 92 --------------------------- 93 r0: Volatile. 94 cr1, cr5-7: Volatile. 95 lr: Volatile. 96 97 Invocation 98 ---------- 99 The vsyscall is performed with a branch-with-link instruction to the vsyscall 100 function address. 101 102 Transactional Memory 103 -------------------- 104 vsyscalls will run in the same transactional state as the caller. A vsyscall 105 may or may not result in the transaction being doomed by hardware.