Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
sigvec(2)							     sigvec(2)

       sigvec -	software signal	facilities

       #include	<signal.h>

       struct sigvec {
       void	 (*sv_handler)();
       sigset_t	 sv_mask;
       int	 sv_flags;

       sigvec(sig, vec,	ovec)
       int sig;
       struct sigvec *vec, *ovec;

       The system defines a set	of signals that	can be delivered to a process.
       Signal delivery resembles the occurrence	of a hardware  interrupt:  the
       signal  is blocked from further occurrence, the current process context
       is saved, and a new one is built.  A process can	specify	a  handler  to
       which  a	signal is delivered, or	specify	that a signal is to be blocked
       or ignored .  A process can also	specify	that a default action is to be
       taken  by  the  system when a signal occurs.  Normally, signal handlers
       execute on the current stack of the process.  This can be changed, on a
       per-handler basis, so that signals are taken on a special signal	stack.

       All signals have	the same priority.  Signal routines execute  with  the
       signal  that  caused  their  invocation	blocked, but other signals can
       occur.  A global	signal mask  defines  the  set	of  signals  currently
       blocked	from  delivery to a process.  The signal mask for a process is
       initialized from	that of	its parent (normally, 0).  It can  be  changed
       with a or call, or when a signal	is delivered to	the process.

       When  a signal condition	arises for a process, the signal is added to a
       set of signals pending for the process.	If the signal is not currently
       blocked	by the process,	it is delivered	to the process.	 When a	signal
       is delivered, the current state of the process is saved,	a  new	signal
       mask  is	 calculated  (as  described  later), and the signal handler is
       invoked.	 The call to the handler is arranged so	that,  if  the	signal
       handling	routine	returns	normally, the process resumes execution	in the
       context from before the signal's	delivery.  If the  process  wishes  to
       resume  in a different context, it must arrange to restore the previous
       context itself.

       When a signal is	delivered to a process,	a new signal mask is installed
       for the duration	of the process's signal	handler	(or until a or call is
       made).  This mask is formed by taking the current signal	 mask,	adding
       the  signal  to	be  delivered, and ORing in the	signal mask associated
       with the	handler	to be invoked.

       The System call assigns a handler for a specific	 signal.   If  vec  is
       nonzero,	it specifies a handler routine and mask	to be used when	deliv-
       ering the specified signal.  Further, if	the SV_ONSTACK bit is  set  in
       sv_flags,  the  system  delivers	 the signal to the process on a	signal
       stack, specified	with If	ovec is	nonzero, the previous handling	infor-
       mation for the signal is	returned to the	user.

       The  following  is  a  list of all signals with names as	in the include

       SIGHUP	 1    Hangup
       SIGINT	 2    Interrupt
       SIGQUIT	 3*   Quit
       SIGILL	 4*   Illegal instruction
       SIGTRAP	 5*   Trace trap
       SIGIOT	 6*   IOT instruction
       SIGEMT	 7*   EMT instruction
       SIGFPE	 8*   Floating point exception
       SIGKILL	 9    Kill (cannot be caught, blocked, 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
       SIGURG	 16.  Urgent condition present on socket
       SIGSTOP	 17+  Stop (cannot be caught, blocked, or ignored)
       SIGTSTP	 18+  Stop signal generated from keyboard
       SIGCONT	 19.  Continue after stop (cannot be blocked)
       SIGCHLD	 20.  Child status has changed
       SIGTTIN	 21+  Background read attempted	from control terminal
       SIGTTOU	 22+  Background write attempted to control terminal
       SIGIO	 23.  I/O is possible on a descriptor (see fcntl(2))
       SIGXCPU	 24   Cpu time limit exceeded (see setrlimit(2))
       SIGXFSZ	 25   File size	limit exceeded (see setrlimit(2))
       SIGVTALRM 26   Virtual time alarm (see setitimer(2))
       SIGPROF	 27   Profiling	timer alarm (see setitimer(2))
       SIGWINCH	 28.  Window size change
       SIGLOST	 29   Lock not reclaimed after server recovery
       SIGUSR1	 30   User-defined signal 1
       SIGUSR2	 31   User-defined signal 2
       SIGCLD	      System V name for	SIGCHLD
       SIGABRT	      X/OPEN name for SIGIOT

       The signals marked with asterisks (*) in	this list cause	a  core	 image
       if  not	caught or ignored.  Explanations of the	meaning	of the periods
       (.)  and	plus signs (+) are included in the following paragraph.

       Once a signal handler is	installed, it remains installed	until  another
       call  is	 made or an is performed.  The default action for a signal can
       be reinstated by	setting	sv_handler to SIG_DFL. This default is	termi-
       nation  (with  a	 core  image  for  signals marked with asterisks (*)),
       except for signals marked with periods (.) or plus signs	(+).   Signals
       marked with periods (.) are discarded if	the action is SIG_DFL. Signals
       marked with plus	signs (+) cause	the process to stop.  If sv_handler is
       SIG_IGN,	 the  signal is	subsequently ignored, and pending instances of
       the signal are discarded.

       If a caught signal occurs during	certain	system calls, the call is nor-
       mally  restarted.  The call can be forced to terminate prematurely with
       an EINTR	error return, by setting the  SV_INTERRUPT  bit	 in  sv_flags.
       The  affected system calls are or on a slow device (such	as a terminal,
       but not a file),	and

       After a or the child inherits all signals, the signal mask, the	signal
       stack, and the restart/interrupt	flags.

       The  system call	resets all caught signals to default action and	resets
       all signals to be caught	on the user  stack.   Ignored  signals	remain
       ignored,	 the signal mask remains the same; signals that	interrupt sys-
       tem calls continue to do	so.

       The mask	specified in vec is not	allowed	to block SIGKILL, SIGSTOP,  or
       SIGCONT.	 This is done silently by the system.

       The  SV_INTERRUPT  flag	is not available in ULTRIX 2.0 or earlier ver-
       sions.  Therefore, it should not	be used	if backward  compatibility  is

Return Values
       A  zero (0) value indicates that	the call succeeded.  A -1 return value
       indicates an error occurred, and	errno is set to	indicated the  reason.

       The system call fails and no new	signal handler is installed, if	one of
       the following occurs:

       [EFAULT]	      Either vec or ovec points	to memory that is not a	 valid
		      part of the process address space.

       [EINVAL]	      Sig is not a valid signal	number.

       [EINVAL]	      An  attempt  is  made  to	ignore or supply a handler for

       [EINVAL]	      An attempt is made to ignore SIGCONT (by default SIGCONT
		      is ignored).

       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
       following table.	 Code is a parameter that  is  either  a  constant  or
       zero.   The  scp	 is  a pointer to the sigcontext structure (defined in
       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 exceptions to sig-
       nals 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

       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 fol-
       lowing 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); CAUSE_BD is
       defined in

       The signal handler can fix the cause of the  exception  and  re-execute
       the instruction,	emulate	the instruction	and then step over it, or per-
       form some nonlocal redirection, such as a or an

       If corrective action  is	 performed  in	the  signal  handler  and  the
       instruction that	caused the exception would then	execute	without	a fur-
       ther 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 instruction 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.  Otherwise, it is incremented by four.  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 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	structure (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).

       For SIGSEGV and SIGBUS errors, the faulting virtual address is saved in
       sc_badvaddr in the signal context structure.

       The SIGTRAPs caused by instructions noted in the	previous table and all
       other  yet  to be defined instructions fill the code parameter with the
       first argument to the instruction (bits 25-16 of	the instruction).

See Also
       kill(1),	kill(2), ptrace(2), sigblock(2),  sigpause(2),	sigsetmask(2),
       sigstack(2), setjmp(3), siginterrupt(3),	tty(4)

				     RISC			     sigvec(2)

Name | Syntax | Description | Return Values | Diagnostics | Notes | See Also

Want to link to this manual page? Use this URL:

home | help