Signals and Syscalls

• To inform you that some data arrived on the network or from the disk, SIGIO.
• To tell you to stop running, SIGTERM or SIGKILL.
  
• To inform you that your code just accessed out of bounds memory, SIGSEGV.
  

• To ask the OS to perform some I/O, like screen output or network traffic. (write)
  
• To ask the OS who you are, or what time it is. (getpid)
  

Writing a Signal Handler

Overall signal delivery looks like this:

1. Something causes an interrupt--a hardware device needs attention, or a program reads a bad memory address, divides by zero, executes an illegal or privileged instruction, etc.
2. The CPU looks up the OS interrupt service routine in the interrupt table (or "interrupt vector", for some strange reason.)
   
3. The OS's interrupt service routine figures out if it can handle the interrupt, or if it should deliver the interrupt to a process as a signal.
4. To deliver a signal, the OS essentially just calls your process's subroutine.
   

#include <signal.h>

void myHandler(int i)
{
	printf("Sorry dude--you just hit signal %d\n",i);
	exit(1);
}

int foo(void) {
	int *badPointer=(int *)0;
	printf("Installing signal handler\n");
	signal(SIGSEGV,myHandler);   /* <------------- */
	printf("Signal handler installed.  Segfaulting...\n");
	(*badPointer)++;
	printf("Back from segfault?!\n");
	return 0;
}
(Executable NetRun Link)

Which on my machine prints out:

Installing signal handler
Signal handler installed.  Segfaulting...
Sorry dude--you just hit signal 11

Signals are available on all POSIX operating systems (including Windows, Linux, Mac OS X), and include:

• SIGSEGV, segmentation fault, is delivered when your program accesses an out-of-bounds memory address. If you manipulate the memory map, you can actually resume from this signal!
• SIGFPE, floating-point (or arithmetic) exception, is delivered when you divide by zero or encounter a problem with floating-point (like a signalling NaN).
  
• SIGILL, illegal instruction, is delivered when your program hits an invalid instruction, usually caused by overwriting your own code or jumping to a bad function pointer.

On UNIX machines, there's also a slightly more sophisticated interface called sigaction.  The signal handler function for sigaction can take a siginfo_t, which includes machine register info.

Signals can also be used to indicate that I/O is ready (SIGIO, enabled using ``fcntl''), that a timer has expired (SIGALRM, SIGPROF, or SIGVPROF, enabled using ``setitimer''), that the operating system wants you to shut down (SIGTERM, SIGQUIT, SIGKILL, all UNIX-specific), that various events have happened on the terminal (SIGHUP, SIGWINCH, SIGPIPE, SIGTTIN, SIGTTOU, all UNIX-specific), or for application-defined purposes (SIGUSR1/SIGUSR2, which must be sent explicitly).  See signal.h for the full list of signals.

Signals, exactly like interrupts, are hence a generic ``catch-all'' notification mechanism, used for a variety of unrelated tasks.

Direct Operating System Calls: Syscalls

push rbx  ; <- we'll be using ebx below, and it's a saved register (hallelujah!)

; System calls are listed in "asm/unistd.h"
mov rax,4 ; the system call number of "write".
mov rbx,1 ; first parameter: 1, the stdout file descriptor
mov rcx,myStr ; data to write
mov rdx,3 ; bytes to write
int 0x80 ; Issue the system call

pop rbx  ; <- restore ebx to its old value 
ret

section .data
myStr:
	db "Yo",0xa

(Try this in NetRun now!)

; "sysenter" instruction call numbers are listed in "asm/unistd_64.h"
mov rax,1 ; the (new) system call number of "write".
mov rdi,1 ; first parameter: 1, the stdout file descriptor
mov rsi,myStr ; data to write
mov rdx,3 ; bytes to write
syscall ; Issue the system call
; leave syscall's return value in rax
ret

section .data
myStr:
	db "Yo",0xa

section .text
(Try this in NetRun now!)