SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
NAME
sigset, sighold, sigrelse, sigignore, sigpause - signal
management
SYNOPSIS
#include <bsd/sys/types.h>
#include <signal.h>
void (*sigset (sig, func))()
int sig;
void (*func)();
int sighold (sig)
int sig;
int sigrelse (sig)
int sig;
int sigignore (sig)
int sig;
int sigpause (sig)
int sig;
DESCRIPTION
These functions provide signal management for application
processes. sigset specifies the system signal action to be
taken upon receipt of signal sig. This action is either
calling a process signal-catching handler func or performing
a system-defined action.
sig can be assigned any one of the following values except
SIGKILL. Machine or implementation dependent signals are
not included (see NOTES below). Each value of sig is a
macro, defined in <signal.h>, that expands to an integer
constant expression.
SIGHUP hangup
SIGINT interrupt
SIGQUIT* quit
SIGILL* illegal instruction (not held when caught)
SIGTRAP* trace trap (not held when caught)
SIGABRT* abort
SIGFPE* floating point exception
SIGKILL kill (can not be caught or ignored)
SIGSYS* bad argument to system call
SIGPIPE write on a pipe with no one to read it
SIGALRM alarm clock
SIGTERM software termination signal
SIGUSR1 user-defined signal 1
SIGUSR2 user-defined signal 2
SIGCLD death of a child (see WARNING below)
SIGPWR power fail (see WARNING below)
SIGPOLL selectable event pending (see NOTES below)
Printed 1/15/91 Page 1
SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
See below under SIG_DFL regarding asterisks (*) in the above
list.
The following values for the system-defined actions of func
are also defined in <signal.h>. Each is a macro that
expands to a constant expression of type pointer to function
returning void and has a unique value that matches no
declarable function.
SIG_DFL - default system action
Upon receipt of the signal sig, the receiving pro-
cess is to be terminated with all of the conse-
quences outlined in exit(2). In addition a ``core
image'' will be made in the current working direc-
tory of the receiving process if sig is one for
which an asterisk appears in the above list and
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 follow-
ing 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
SIG_IGN - ignore signal
Any pending signal sig is discarded and the system
signal action is set to ignore future occurrences of
this signal type.
SIG_HOLD - hold signal
The signal sig is to be held upon receipt. Any
pending signal of this type remains held. Only one
signal of each type is held.
Otherwise, func must be a pointer to a function, the
signal-catching handler, that is to be called when signal
sig occurs. In this case, sigset specifies that the process
will call this function upon receipt of signal sig. Any
pending signal of this type is released. This handler
Page 2 Printed 1/15/91
SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
address is retained across calls to the other signal manage-
ment functions listed here.
When a signal occurs, the signal number sig will be passed
as the only argument to the signal-catching handler. Before
calling the signal-catching handler, the system signal
action will be set to SIG_HOLD . During normal return from
the signal-catching handler, the system signal action is
restored to func and any held signal of this type released.
If a non-local goto (longjmp) is taken, then sigrelse must
be called to restore the system signal action and release
any held signal of this type.
In general, upon return from the signal-catching handler,
the receiving process will resume execution at the point it
was interrupted. However, when a signal is caught during a
read(2), a write(2), an open(2), or an ioctl(2) system call
during a sigpause system call, or during a wait(2) system
call that does not return immediately due to the existence
of a previously stopped or zombie process, the signal-
catching handler will be executed and then the interrupted
system call may return a -1 to the calling process with
errno set to EINTR.
sighold and sigrelse are used to establish critical regions
of code. sighold is analogous to raising the priority level
and deferring or holding a signal until the priority is
lowered by sigrelse. sigrelse restores the system signal
action to that specified previously by sigset.
sigignore sets the action for signal sig to SIG_IGN (see
above).
sigpause suspends the calling process until it receives a
signal, the same as pause(2). However, if the signal sig
had been received and held, it is released and the system
signal action taken. This system call is useful for testing
variables that are changed on the occurrence of a signal.
The correct usage is to use sighold to block the signal
first, then test the variables. If they have not changed,
then call sigpause to wait for the signal.
ERRORS
sigset will fail if one or more of the following are true:
[EINVAL] sig is an illegal signal number (includ-
ing SIGKILL) or the default handling of
sig cannot be changed.
[EINTR] A signal was caught during the system
call sigpause.
Printed 1/15/91 Page 3
SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
DIAGNOSTICS
Upon successful completion, sigset returns the previous
value of the system signal action 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
<signal.h>.
For the other functions, upon successful completion, a value
of 0 is returned. Otherwise, a value of -1 is returned and
errno is set to indicate the error.
SEE ALSO
kill(2), pause(2), signal(2), wait(2), setjmp(3C).
R2010 Floating Point Coprocessor Architecture
R2360 Floating Point Board Product Description
WARNING
Two signals that behave differently than the signals
described above exist in this release of the system:
SIGCLD death of a child (reset when caught)
SIGPWR power fail (not reset when caught)
For these signals, func is assigned one of three values:
SIG_DFL, SIG_IGN, or a function address. The actions
prescribed by these values are as follows:
SIG_DFL - ignore signal
The signal is to be ignored.
SIG_IGN - ignore signal
The signal is to be ignored. Also, if sig is
SIGCLD, the calling process's child processes will
not create zombie processes when they terminate
[see exit(2)].
function address - catch signal
If the signal is SIGPWR, the action to be taken is
the same as that described above for func equal to
function address. The same is true if the signal
is SIGCLD with one exception: while the process
is executing the signal-catching function, any
received SIGCLD signals will be ignored. (This is
the default action.)
The SIGCLD affects two other system calls [wait(2), and
exit(2)] in the following ways:
wait If the func value of SIGCLD is set to SIG_IGN 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
Page 4 Printed 1/15/91
SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
errno set to ECHILD.
exit If in the exiting process's parent process the
func value of SIGCLD is set to SIG_IGN , 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
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.
NOTES
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(2) call [see streamio(7)].
Otherwise, the process will never receive SIGPOLL.
For portability, applications should use only the symbolic
names of signals rather than their values and use only the
set of signals defined here. The action for the signal SIG-
KILL can not be changed from the default system action.
Specific implementations may have other implementation-
defined signals. Also, additional implementation-defined
arguments may be passed to the signal-catching handler for
hardware-generated signals. For certain hardware-generated
signals, it may not be possible to resume execution at the
point of interruption.
The signal type SIGSEGV is reserved for the condition that
occurs on an invalid access to a data object. If an imple-
mentation can detect this condition, this signal type should
be used.
The other signal management functions, signal(2) and
pause(2), should not be used in conjunction with these rou-
tines for a particular signal type.
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
Printed 1/15/91 Page 5
SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
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
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
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().
Page 6 Printed 1/15/91
SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
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.
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) and 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;
Printed 1/15/91 Page 7
SIGSET(2-SysV) RISC/os Reference Manual SIGSET(2-SysV)
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 8 Printed 1/15/91