1

I am having trouble understanding if software interrupts are still generated when system calls occur in x86. For example, I had thought a processor sends an interrupt to itself (a software interrupt specifically) when a system call is generated. Then this would generate the need to perform all the work of setting up the SS and CS before executing the specific SYSCALL/SYSRET instruction. I am know wondering if this really is the case. I am doing work with gem5, and I noticed there doesn't seem to be an intercepting point where a Software Interrupt is generated. But instead, it seems like the SYSCALL/SYSRET instructions are executed outright without an interrupt being generated (I have been using debug flags to see if anything gets generated when I perform a system call in my own applications). So is there an intercepting point with the new SYSCALL/SYSRET instructions between when a system call is first "recognized" in x86 and when the kernel takes over and performs the actual system call? I had thought x86 captures the vector number (to look up in the IVT) and stores the system call number in a register the kernel knows should hold the system call number. Any clarification would be greatly appreciated.

ballsmahoney
  • 141
  • 1
  • 6
  • 1
    No, `syscall` doesn't generate an interrupt as `int` would. That's why it is faster. It uses a specific MSR to load the correct values for the segment and the instruction pointer. You can find the detailed info in the Intel manual. – Margaret Bloom Jun 28 '21 at 15:04
  • Software puts the call number in EAX *before* running `int 0x80` or `syscall` or `sysenter`. The x86 CPU itself doesn't care and isn't involved in how user-space passes a call number and other args into the kernel. If user-space does `int 0x80`, the kernel doesn't get `0x80` in a register. (So if the kernel needs to tell the difference between different interrupt numbers, it needs different entry points. Just like the syscall entry point is different from any interrupt, because it's *not* an interrupt handler.) – Peter Cordes Jun 28 '21 at 15:35
  • semi-related: [What happens if you use the 32-bit int 0x80 Linux ABI in 64-bit code?](https://stackoverflow.com/q/46087730) has some links to the kernel side of Linux's system-call handling, showing how the kernel uses RAX as an index into a table of function pointers. – Peter Cordes Jun 28 '21 at 15:36
  • Thank you for the clarification. I was trying to determine why system calls were not mentioned in the latest Intel manual's Interrupt and Exception handling chapter. However, one thing I still am stuck on is how we go from a C program which executes a system call, say read(), and how this gets "translated" into SYSCALL in x86. Does x86 know to call SYSCALL based on libc's implementation of system calls? – ballsmahoney Jun 28 '21 at 20:55
  • 1
    The libc implementation will simply use an inlined assembly block with a `syscall` instruction or a generic thunk function defined in a .S file or both. It's not the processor that knows what to do, it is the software. An OS could implement a syscall with many different and exotic mechanisms (e.g. through a fault), it's up to the software to know how to communicate with the OS. The CRT takes care of that by providing andabstraction layer to a standard (more or less) interface. – Margaret Bloom Jun 29 '21 at 08:27

0 Answers0