SIGNAL(2-SVR3) RISC/os Reference Manual SIGNAL(2-SVR3)
NAME
signal - specify what to do upon receipt of a signal
SYNOPSIS
#include <bsd/sys/types.h>
#include <signal.h>
void (*signal (sig, func))()
int sig;
void (*func)();
DESCRIPTION
signal allows the calling process to choose one of three
ways in which it is possible to handle the receipt of a
specific signal. sig specifies the signal and func speci-
fies the choice.
sig can be assigned any one of the following except SIGKILL:
Name Default Event
SIGHUP Exit hangup
SIGINT Exit interrupt
SIGQUIT * quit
SIGILL * illegal instruction
SIGTRAP * trace trap
SIGABRT * abort
SIGEMT * EMT instruction
SIGFPE * floating point exception
SIGKILL Exit kill (cannot be caught or ignored)
SIGBUS * bus error
SIGSEGV * segmentation violation
SIGSYS * bad argument to system call
SIGPIPE Exit write on a pipe with no one to read it
SIGALRM Exit alarm clock
SIGTERM Exit software termination signal
SIGUSR1 Exit User defined signal 1
SIGUSR2 Exit User defined signal 2
SIGCLD Ignore child status has changed
SIGSTOP Stop stop (cannot be caught or ignored)
SIGTSTP Stop stop signal generated from keyboard
SIGPOLL Exit selectable event pending
SIGIO Ignore I/O is possible on a descriptor (see fcntl(2))
SIGURG Ignore urgent condition present on socket
SIGWINCH Ignore Window size change
SIGVTALRM Exit virtual time alarm (see getitimer(2))
SIGPROF Exit profiling timer alarm (see getitimer(2))
SIGCONT Stop continue after stop
SIGTTIN Stop background read attempted from control terminal
SIGTTOU Stop background write attempted to control terminal
SIGXCPU * cpu time limit exceeded
SIGXFSZ * file size limit exceeded
SIGLOST Exit resource lost (eg, record-lock)
Printed 11/19/92 Page 1
SIGNAL(2-SVR3) RISC/os Reference Manual SIGNAL(2-SVR3)
func is assigned one of three values: SIGDFL, SIGIGN, or
a function address. SIGDFL, and SIGIGN, are defined in
the include file <signal.h>. Each is a macro that expands
to a constant expression of type pointer to function return-
ing void, and has a unique value that matches no declarable
function.
The actions prescribed by the values of func are as follows:
SIGDFL default disposition selected from the following:
Exit On receipt of sig, the receiving process to
be terminated with all of the consequences
outlined in exit(2).
* These signals, in addition to terminating
the process, produce a ``core image'' in
the current working directory of the pro-
cess, if the following conditions are met:
The effective user ID and the real user
ID of the receiving process are equal.
An ordinary file named core exists and
is writable or can be created. If the
file must be created, it will have the
following properties:
a mode of 0666 modified by the file
creation mask [see umask(2)].
a file owner ID that is the same as
the effective user ID of the
receiving process.
a file group ID that is the same as
the effective group ID of the
receiving process.
Stop On receipt of sig, the receiving process is
to stop.
Ignore On receipt of sig, the receiving process is
to ignore it. This is identical to setting
the disposition to SIGIGN.
SIGIGN On receipt of sig, the receiving process is to
ignore it. Also, if sig is SIGCLD, children of the
calling process will not become zombie processes
when they terminate [see exit(2)].
Note: the signal SIGKILL cannot be ignored.
Page 2 Printed 11/19/92
SIGNAL(2-SVR3) RISC/os Reference Manual SIGNAL(2-SVR3)
func Upon receipt of the signal sig, the receiving pro-
cess is to execute the signal-catching function
pointed to by func. The signal number sig will be
passed as the only argument to the signal-catching
function. Additional arguments are passed to the
signal-catching function for hardware-generated
signals. Before entering the signal-catching func-
tion, the value of func for the caught signal will
be set to SIGDFL unless the signal is SIGILL,
SIGTRAP, or SIGPWR.
Upon return from the signal-catching function, the
receiving process will resume execution at the
point it was interrupted.
When a signal that is to be caught occurs during a
read(2), a write(2), an open(2), or an ioctl(2)
system call on a slow device (like a terminal; but
not a file), during a pause(2) system call, or dur-
ing a wait(2) system call that does not return
immediately due to the existence of a previously
stopped or zombie process, the signal catching
function will be executed and then the interrupted
system call may return a -1 to the calling process
with errno set to EINTR.
signal will not catch an invalid function argument,
func, and results are undefined when an attempt is
made to execute the function at the bad address.
Note: The signal SIGKILL cannot be caught.
A call to signal cancels a pending signal sig except for a
pending SIGKILL signal.
signal will fail if sig is an illegal signal number, includ-
ing SIGKILL.
SIGCLD affects the wait, and exit system calls as follows:
wait If the func value of SIGCLD is set to SIGIGN and
a wait is executed, the wait will block until all
of the calling process's child processes ter-
minate; it will then return a value of -1 with
errno set to ECHILD.
exit If in the exiting process's parent process the
func value of SIGCLD is set to SIGIGN, the exit-
ing process will not create a zombie process.
When processing a pipeline, the shell makes the last pro-
cess in the pipeline the parent of the proceeding
Printed 11/19/92 Page 3
SIGNAL(2-SVR3) RISC/os Reference Manual SIGNAL(2-SVR3)
processes. A process that may be piped into in this
manner (and thus become the parent of other processes)
should take care not to set SIGCLD to be caught.
SIGPOLL is issued when a file descriptor corresponding to a
STREAMS [see intro(2)] file has a "selectable" event pend-
ing. A process must specifically request that this signal
be sent using the I_SETSIG ioctl call. Otherwise, the pro-
cess will never receive SIGPOLL.
SEE ALSO
intro(2), kill(2), pause(2), ptrace(2), wait(2), setjmp(3C),
sigset(2).
kill(1) in the User's Reference Manual.
R2010 Floating Point Coprocessor Architecture
R2360 Floating Point Board Product Description
DIAGNOSTICS
Upon successful completion, signal returns the previous
value of func for the specified signal sig. Otherwise, a
value of SIG_ERR is returned and errno is set to indicate
the error. SIG_ERR is defined in the include file
<signal.h>.
NOTES (MIPS)
The handler routine can be declared:
void 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 <sys/sbd.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
Page 4 Printed 11/19/92
SIGNAL(2-SVR3) RISC/os Reference Manual SIGNAL(2-SVR3)
User Breakpoint (used by debuggers) SIGTRAP BRK_USERBP
Kernel Breakpoint (used by prom) SIGTRAP BRK_KERNELBP
aken 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
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 <sys/sbd.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.
Printed 11/19/92 Page 5
SIGNAL(2-SVR3) RISC/os Reference Manual SIGNAL(2-SVR3)
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
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 <sys/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).
Page 6 Printed 11/19/92