SIGNAL(2) GENIX Programmer's Manual SIGNAL(2)
NAME
signal - catch or ignore signals
SYNOPSIS
#include <signal.h>
(*signal(sig, func))()
void (*func)();
DESCRIPTION
N.B.: The system currently supports two signal implementations. The
one described here is standard in version 7 UNIX systems, and is
retained for backward compatabililty. The one described in sig-
sys(2) as supplemented by sigset(3) provides for the needs of the
job control mechanisms used by csh(1), and corrects the bugs in this
older implementation of signals, allowing programs which process
interrupts to be written reliably.
A signal is generated by some abnormal event, initiated either by
user at a terminal (quit, interrupt), by a program error (bus error,
etc.), or by request of another program (kill). Normally all sig-
nals cause termination of the receiving process, but a signal call
allows them either to be ignored or to cause an interrupt to a
specified location. Here is the list of standard version 7 signals
with names as specified in the file /usr/include/signal.h; see sig-
sys(2) for additional signals.
SIGHUP 1 hangup
SIGINT 2 interrupt
SIGQUIT 3* quit
SIGILL 4* illegal instruction (not reset when caught)
SIGTRAP 5* trace trap (not reset when caught)
SIGIOT 6* IOT instruction
SIGEMT 7* EMT instruction
SIGFPE 8* floating point exception
SIGKILL 9 kill (cannot be caught or ignored)
SIGBUS 10* bus error
SIGSEGV 11* segmentation violation
SIGSYS 12* bad argument to system call
SIGPIPE 13 write on a pipe with no one to read it
SIGALRM 14 alarm clock
SIGTERM 15 software termination signal
16 unassigned
The starred signals in the list above cause a core image if not
caught or ignored.
If func is SIG_DFL, the default action for signal sig is reinstated;
this default is termination, sometimes with a core image. If func
is SIG_IGN the signal is ignored. Otherwise when the signal occurs
func will be called with the signal number as argument. A return
from the function will continue the process at the point it was
Printed 11/16/83 1
SIGNAL(2) GENIX Programmer's Manual SIGNAL(2)
interrupted.
Except as indicated, a signal is reset to SIG_DFL after being
caught. Thus if it is desired to catch every such signal, the
catching routine must issue another signal call.
If, when using this (older) signal interface, a caught signal occurs
during certain system calls, the call terminates prematurely. In
particular this can occur during an ioctl(2), read(2), or write(2)
on a slow device (such as a terminal, but not a file); and during
pause(2) or wait(2). When such a signal occurs, the saved user
status is arranged in such a way that when return from the signal-
catching routine takes place, it will appear that the system call
returned an error status. The user's program may then, if it
wishes, re-execute the call.
The value of signal is the previous (or initial) value of func for
the particular signal.
After a fork(2) the child inherits all signals. Exec(2) resets all
caught signals to default action.
If a process is using the mechanisms of sigsys(2) and sigset(3) many
of these calls are automatically restarted (See sigsys(2) and
jobs(3) for details).
GENIX IMPLEMENTATION
When a signal occurs, the kernel does not transfer control directly
to the specified signal handler. Instead, the assembly-level rou-
tine sigentry(3) is called. This routine saves the temporary regis-
ters and psr flags and then calls the specified signal handler.
When the signal handler returns, sigentry restores the temporary
registers and psr flags and returns to the interrupted routine.
Such an intermediate routine is necessary because C routines assume
that the registers r0, r1, r2, and the psr flags can be used without
saving them.
The crt0 startup module tells the kernel where the sigentry routine
is by executing a signal(2) system call using the special signal
number SIGCATCHALL. Then when a signal occurs, the kernel calls the
assembly-level routine in such that a way that it appears as if the
following sequence of instructions was executed:
movd signal_number,tos ; push signal number
lxpd signal_routine,tos ; push signal handler descriptor
cxpd sigentry ; call low-level routine
SEE ALSO
Printed 11/16/83 2
SIGNAL(2) GENIX Programmer's Manual SIGNAL(2)
DIAGNOSTICS
The value (int)-1 is returned if the given signal is out of range.
BUGS
For reasons of efficiency, the floating point registers are not
saved when calling a signal handler. Thus a signal handler should
not use floating point instructions if it expects to return to the
interrupted code. This problem can be fixed if you write your own
version of the sigentry(3) routine to save all of the floating point
registers.
The traps should be distinguishable by extra arguments to the signal
handler, and all hardware supplied parameters should be made avail-
able to the signal routine.
If a repeated signal arrives before the last one can be reset, it
cannot be caught (however this is not true if you use sigsys(2) and
sigset(3)).
The type specification of the routine and its func argument are
problematical.
Printed 11/16/83 3