System call transition to system call table

Question

When a system call is invoked by a user program, a software interrupt (trap) is raised, control first passes to the fixed location of the interrupt vector (IR) which contains the ISR associated with the interrupt, and then to the system call table which contains the pointer to the system call code? That is, it’s not clear to me what happens after the ISR is executed and the transition to the system call table.

• stark: Are you interested in a particular architecture? It varies slightly.
• sawdust: Study linux-kernel-labs.github.io/refs/heads/master/lectures/…
• Fabio: @stark No,basically I am having trouble to understand what happens after ISR execution mapped to a system call. What are the steps operating system follows to reach the system call table. Does ISR have a reference to the system call procedure in the system call table?
• stark: On x86 the index into the syscall table is passed as an argument. See stackoverflow.com/q/10583891/1216776
• Ian Abbott: On most architectures, the system call number and up to 6 arguments are passed in registers. If an architecture had insufficient registers, the information could be passed on the stack, although I cannot think of any Linux-supported architectures that do that.

Answer 1

The system call table is an array of function pointers that contains the list of all the system calls for the operating system. So, basically, the system call table is a dispatcher to map system call numbers to kernel functions; the system call number is the index into the array in the system call table which points to a specific kernel function.

For syscalls, generally, you don't handle them with ISR but by triggering software functions and instructions (e.g., entry_SYSCALL_64). So, when a syscall happens, you move from user space to the kernel space and starts execution of the system call entry point which uses the sys_call_table[] to get the function to execute in relation to the syscall number.

The ISR is software function the kernel runs in response to specific interrupts, associated to special events (ex. in drivers, hardware devices) and it should run immediately without blocks. For those type of interrupts management, Kernel creates an array of Interrupt Descriptors in memory, called Interrupt Descriptor Table (IDT), which contains the descriptors pointing to the kernel ISRs. Within this context, when idtr (index for the IDT relate to the interrupt happend) points to a syscall descriptor, the descriptor in the IDT will be associated to a syscall handler function that will follow the process above.