For signal in linux, who calls int 0x80?

1
votes

system call, exception, divided by 0, etc they all have the same vector entry in linux. If in x86, it is 0x80, right ? So what about signal ? Does OS also use int 0x80 for signal to a process ? if yes, who calls it ? We know if you want trap in kernel, you have to call int 0x80 or its wrapper like system call, but for the case of signal, who calls 0x80 ?

3
clinuxassembly
You are probably confused. A signal is sent by the kernel to the application process (so it does not need any int or trap). Read basepath.com/aup advancedlinuxprogramming.com tldp.org/HOWTO/Assembly-HOWTO – Basile Starynkevitch
int 80h is used to generate interrupt (CPU will stop execution of current code and will jump into vector indexed by int number). "divide by zero" is other way to generate an interrupt (it is generated by CPU itself when second argument of DIV is zero), and it handled like an int 0h. Vector element points to specific Interrupt handler, which is part of OS kernel. Handler will check what to do, the behaviour is different for each int number. E.g. for 80h the handler will start selected system call (with switch from user mode to kernel mode); for 0h it will generate a signal. – osgx

3 Answers

6
votes

First of all,. int 0x80 is not used by modern OS on modern Intel CPUs for a long time now. the sysenter instruction is typically used noways (see: http://siyobik.info/main/reference/instruction/SYSENTER).

As for signals, you have two cases -

If the target of the signal is NOT running on the CPU when the signal is sent, then sending a signal is nothing more then marking a bit in a kernel data structure that indicated to the kernel that when it schedules that process back into the CPU to put the program counter to the signal handling routine rather then the original PC.

If however the program you send the signal to is running on a CPU when a signal is sent, the signal is triggered as an interrupt - if the signal is synchronous (such as divide by zero exception), the interrupt is the exception interrupt that is generated from the CPU core. If the signal is async (such as another process running on another core sending a signal), the interrupt is the inter processor interrupt sent from that other core.

So, no int 0x80 anywhere then :-)

4
votes

Basically signals are not like interrupts. The user-level process is periodically interrupted by kernel. When it is about to send a signal to the user-level process, the kernel just makes the instruction pointer of the user-level process to point to the signal handler code before scheduling it again. It also sets the stacks and other registers accordingly.

3
votes

When you call a syscall, you use int 0x80.

However, when you receive a signal, whether from another process or SIGSEGV or SIGFPE, you don't have to call int 0x80 in order to get it.

What happens is that the timer interrupt that handles calling sched_tick also checks if there is a signal pending before returning control to the user-space process, and if one exists (and the signal mask allows it), calls the appropriate signal handler.