SIGNAL(3C-BSD) RISC/os Reference Manual SIGNAL(3C-BSD)
NAME
signal - simplified software signal facilities
SYNOPSIS
#include <signal.h>
(*signal(sig, func))()
int (*func)();
DESCRIPTION
signal is a simplified interface to the more general
sigvec(2) facility.
A signal is generated by some abnormal event, initiated by a
user at a terminal (quit, interrupt, stop), by a program
error (bus error, etc.), by request of another program
(kill), or when a process is stopped because it wishes to
access its control terminal while in the background (see
tty(4)). Signals are optionally generated when a process
resumes after being stopped, when the status of child
processes changes, or when input is ready at the control
terminal. Most signals cause termination of the receiving
process if no action is taken; some signals instead cause
the process receiving them to be stopped, or are simply dis-
carded if the process has not requested otherwise. Except
for the SIGKILL and SIGSTOP signals, the signal call allows
signals either to be ignored or to cause an interrupt to a
specified location. The following is a list of all signals
with names as in the include file <signal.h>:
SIGHUP 1 hangup
SIGINT 2 interrupt
SIGQUIT 3* quit
SIGILL 4* illegal instruction
SIGTRAP 5* trace trap
SIGIOT 6* IOT instruction
SIGXCPU 7 cpu time limit exceeded
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
SIGUSR1 16 User defined signal 1
SIGUSR2 17 User defined signal 2
SIGCHLD 18@ child status has changed
SIGXFSZ 19 file size limit exceeded
SIGSTOP 20'
|+'stop (cannot be caught or ignored)
SIGTSTP 21'
|+'stop signal generated from keyboard
SIGIO 23@ I/O is possible on a descriptor (see fcntl(2))
Printed 11/19/92 Page 1
SIGNAL(3C-BSD) RISC/os Reference Manual SIGNAL(3C-BSD)
SIGURG 24@ urgent condition present on socket
SIGWINCH 25@ Window size change
SIGVTALRM 26 virtual time alarm (see getitimer(2))
SIGPROF 27 profiling timer alarm (see getitimer(2))
SIGCONT 28@ continue after stop
SIGTTIN 29'
|+'background read attempted from control terminal
SIGTTOU 30'
|+'background write attempted to control terminal
SIGLOST 31 resource lost (eg, record-lock)
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 (with a core image
for starred signals) except for signals marked with @ or
'
|+'. Signals marked with @ are discarded if the action is
SIG_DFL; signals marked with '
|+' cause the process to stop.
If func is SIG_IGN the signal is subsequently ignored and
pending instances of the signal are discarded. Otherwise,
when the signal occurs further occurrences of the signal are
automatically blocked and func is called.
A return from the function unblocks the handled signal and
continues the process at the point it was interrupted.
Unlike previous signal facilities, the handler func remains
installed after a signal has been delivered.
If a caught signal occurs during certain system calls, caus-
ing the call to terminate prematurely, the call is automati-
cally restarted. In particular this can occur during a
read(2) or write(2) on a slow device (such as a terminal;
but not a file) and during a wait(2).
The value of signal is the previous (or initial) value of
func for the particular signal.
After a fork(2) or vfork(2) the child inherits all signals.
execve(2) resets all caught signals to the default action;
ignored signals remain ignored.
RETURN VALUE
The previous action is returned on a successful call. Oth-
erwise, -1 is returned and errno is set to indicate the
error.
ERRORS
signal will fail and no action will take place if one of the
following occur:
[EINVAL] sig is not a valid signal number.
[EINVAL] An attempt is made to ignore or supply a handler
Page 2 Printed 11/19/92
SIGNAL(3C-BSD) RISC/os Reference Manual SIGNAL(3C-BSD)
for SIGKILL or SIGSTOP.
[EINVAL] An attempt is made to ignore SIGCONT (by default
SIGCONT is ignored).
SEE ALSO
cacheflush(2) kill(2), ptrace(2), sigblock(2), sigpause(2),
sigreturn(2), sigsetmask(2), sigstack(2), sigvec(2),
emulate_branch(3), fpc(3), setjmp(3), tty(4).
kill(1) in the User's Reference Manual.
R2010 Floating Point Coprocessor Architecture Engineering
Description
R2360 Floating Point Board Product Description
NOTES (MIPS)
The handler routine can be declared:
handler(sig, code, scp)
int sig, code;
struct sigcontext *scp;
Here sig is the signal number. MIPS hardware exceptions are
mapped to specific signals as defined by the table below.
code is a parameter that is either a constant as given below
or zero. scp is a pointer to the sigcontext structure
(defined in <signal.h>), that is the context at the time of
the signal and is used to restore the context if the signal
handler returns.
The following defines the mapping of MIPS hardware excep-
tions to signals and codes. All of these symbols are
defined in either <signal.h> or <mips/cpu.h>:
Hardware exception Signal Code
Integer overflow SIGFPE EXC_OV
Segmentation violation SIGSEGV SEXC_SEGV
Illegal Instruction SIGILL EXC_II
Coprocessor Unusable SIGILL SEXC_CPU
Data Bus Error SIGBUS EXC_DBE
Instruction Bus Error SIGBUS EXC_IBE
Read Address Error SIGBUS EXC_RADE
Write Address Error SIGBUS EXC_WADE
User Breakpoint (used by debuggers) SIGTRAP BRK_USERBP
Kernel Breakpoint (used by prom) SIGTRAP BRK_KERNELBP
Taken Branch Delay Emulation SIGTRAP BRK_BD_TAKEN
Not Taken Branch Delay Emulation SIGTRAP BRK_BD_NOTTAKEN
User Single Step (used by debuggers) SIGTRAP BRK_SSTEPBP
Overflow Check SIGTRAP BRK_OVERFLOW
Divide by Zero Check SIGTRAP BRK_DIVZERO
Range Error Check SIGTRAP BRK_RANGE
Printed 11/19/92 Page 3
SIGNAL(3C-BSD) RISC/os Reference Manual SIGNAL(3C-BSD)
When a signal handler is reached, the program counter in the
signal context structure (sc_pc) points at the instruction
that caused the exception as modified by the branch delay
bit in the cause register. The cause register at the time
of the exception is also saved in the sigcontext structure
(sc_cause). If the instruction that caused the exception is
at a valid user address it can be retrieved with the follow-
ing code sequence:
if (scp->sc_cause & CAUSE_BD) {
branch_instruction = *(unsigned long *)(scp->sc_pc);
exception_instruction = *(unsigned long *)(scp->sc_pc + 4);
} else
exception_instruction = *(unsigned long *)(scp->sc_pc);
Where CAUSE_BD is defined in <mips/cpu.h>.
The signal handler may fix the cause of the exception and
re-execute the instruction, emulate the instruction and then
step over it or perform some non-local goto such as a
longjump() or an exit().
If corrective action is performed in the signal handler and
the instruction that caused the exception would then execute
without a further exception, the signal handler simply
returns and re-executes the instruction (even when the
branch delay bit is set).
If execution is to continue after stepping over the instruc-
tion that caused the exception the program counter must be
advanced. If the branch delay bit is set the program
counter is set to the target of the branch else it is incre-
mented by 4. This can be done with the following code
sequence:
if (scp->sc_cause & CAUSE_BD)
emulate_branch(scp, branch_instruction);
else
scp->sc_pc += 4;
emulate_branch() modifies the program counter value in the
sigcontext structure to the target of the branch instruc-
tion. See emulate_branch(3) for more details.
Floating point exceptions do not raise a SIGFPE unless the
proper trap enable bit of the hardware control and status
register is set. See set_fpc_csr(3).
For SIGFPE's generated by floating-point instructions (code
== 0), the floating-point control and status register at the
time of the exception is also saved in the sigcontext struc-
ture (sc_fpc_csr). This register has the information on
Page 4 Printed 11/19/92
SIGNAL(3C-BSD) RISC/os Reference Manual SIGNAL(3C-BSD)
which exceptions have occurred. When a signal handler is
entered the register contains the value at the time of the
exception but with the exceptions bits cleared. On a return
from the signal handler the exception bits in the floating-
point control and status register are also cleared so that
another SIGFPE will not occur (all other bits are restored
from sc_fpc_csr).
If the floating-point unit is a R2360 (a floating-point
board) and a SIGFPE is generated by the floating-point unit
(code == 0) then the program counter does not point at the
instruction that caused the exception. In this case the
instruction that caused the exception is in the floating-
point instruction exception register. The floating-point
instruction exception register at the time of the exception
is also saved in the sigcontext structure (sc_fpc_eir). In
this case the instruction that caused the exception can be
retrieved with the following code sequence:
union fpc_irr fpc_irr;
fpc_irr.fi_word = get_fpc_irr();
if (sig == SIGFPE && code == 0 &&
fpc_irr.fi_struct.implementation == IMPLEMENTATION_R2360)
exception_instruction = scp->sc_fpc_eir;
The union fpc_irr, and the constant IMPLEMENTATION_R2360 are
defined in <mips/fpu.h>. For the description of the routine
get_fpc_irr() see fpc(3). All other floating-point imple-
mentations are handled in the normal manner with the
instruction that caused the exception at the program counter
as modified by the branch delay bit.
For SIGSEGV and SIGBUS errors the faulting virtual address
is saved in sc_badvaddr in the signal context structure.
The SIGTRAP's caused by break instructions noted in the
above table and all other yet to be defined break instruc-
tions fill the code parameter with the first argument to the
break instruction (bits 25-16 of the instruction).
Printed 11/19/92 Page 5