Commit | Line | Data |
---|---|---|
7b8845a2 NP |
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. |