| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| spo600:syscalls [2025/02/11 19:28] – [x86 64-bit] chris | spo600:syscalls [2025/02/19 16:39] (current) – [Syscall] chris |
|---|
| The system call (//syscall//) mechanism is used by applications to access kernel services. The userland (application/non-kernel) program loads certain registers designating the system service (syscall) desired and the arguments to that syscall, then invokes a software [[Computer_Architecture#Interrupts_and_Exceptions|interrupt]] or exception request which transfers control to the operating system kernel. Note that switching to kernel mode requires a change of [[Computer_Architecture#Execution_State,_Priviledge_State,_Rings,_or_Privilege_Level|processor mode]] (sometimes call the privilege level or exception level), because the kernel has access to instructions, memory structures, memory areas, and devices which userland programs can't access. The syscall numbers may vary between architectures, and the registers as well as the method used to invoke syscalls are architecture-specific. The processor modes and activity involved in a userland-to-kernel switch also vary by architecture. | The system call (//syscall//) mechanism is used by applications to access kernel services. The userland (application/non-kernel) program loads certain registers designating the system service (syscall) desired and the arguments to that syscall, then invokes a software [[Computer_Architecture#Interrupts_and_Exceptions|interrupt]] or exception request which transfers control to the operating system kernel. Note that switching to kernel mode requires a change of [[Computer_Architecture#Execution_State,_Priviledge_State,_Rings,_or_Privilege_Level|processor mode]] (sometimes call the privilege level or exception level), because the kernel has access to instructions, memory structures, memory areas, and devices which userland programs can't access. The syscall numbers may vary between architectures, and the registers as well as the method used to invoke syscalls are architecture-specific. The processor modes and activity involved in a userland-to-kernel switch also vary by architecture. |
| |
| High-level languages wrap the syscall interface in basic wrappers or more advanced mechanisms. For example, in C, the //write// syscall can be accessed through the generic ''syscall'' wrapper, the ''write()'' wrapper, or through more complex functions such as ''printf()''. [[Assembly Language|Assembly language]] programs will often access syscalls directly. | High-level languages wrap the syscall interface in basic wrappers or more advanced mechanisms. For example, in C, the //write// syscall can be accessed through the generic ''syscall'' wrapper, the ''write()'' wrapper, or through more complex functions such as ''puts'' or ''printf()''. [[Assembly Language|Assembly language]] programs will often access syscalls directly. |
| |
| ===== Syscall Mechanism ===== | ===== Syscall Mechanism ===== |
| #define __NR_write 1</code> | #define __NR_write 1</code> |
| |
| You can use the ''ausyscall'' utility, which part of the Linux //audit// package, to determine the number for a given syscall on the particular platform: | You can use the ''ausyscall'' utility, which part of the Linux //audit// package, to determine the number for a given syscall on a particular platform: |
| |
| <code> | <code> |
| process_vm_writev 271</code> | process_vm_writev 271</code> |
| |
| Note that the syscall table is searched by name, and in the examples above the text "write" matches five different syscalls. The architecture defaults to the current platform if not specified. | Note that ''ausyscall'' searches the syscall table by name, and in the examples above the text "write" partially matches five different syscalls. The architecture defaults to the current platform if not specified. |
| |
| ==== Syscall arguments and return values ==== | ==== Syscall arguments and return values ==== |
| gcc foo.S -o foo</code> | gcc foo.S -o foo</code> |
| |
| Note: When the assembler is invoked through gcc, C initialization code is inserted into the binary, which increases its size. This initialization uses the entry point ''_start'' and expects your code to have the entry point ''main''. However, when the assembler is invoked directly, the C initialization code is not inserted, and the entry point should be ''start''. | Note: When the assembler is invoked through gcc, C initialization code is inserted into the binary, which increases its size. This initialization uses the entry point ''_start'' and expects your code to have the entry point ''main''. However, when the assembler is invoked directly, the C initialization code is not inserted, and the entry point should be ''_start''. |
| |
| Using either of these approaches, you can use the ''<nowiki>__</nowiki>NR_//xxxx//'' macros in your assembler code: | Using either of these approaches, you can use the ''<nowiki>__</nowiki>NR_//xxxx//'' macros in your assembler code: |
