Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ siginfo(5) — DG/UX R4.11MU05

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

sde-target(1)

sigaction(2)

waitid(2)

signal(5)



siginfo(5)                     DG/UX R4.11MU05                    siginfo(5)


NAME
       siginfo - signal generation information

SYNOPSIS
       #include <signal.h>
       or
       #include <sys/siginfo.h>

DESCRIPTION
       When a process has caught a signal, it may have access to additional
       information describing why the system generated the signal.  This
       information may be passed as an argument to the invoked signal
       handler, depending upon the system call that was used to establish
       the handler and current software development environment [see
       sde-target(1)].

       There are two versions of the signal information structure: struct
       siginfo (defined in signal.h) and struct siginfot (defined in
       sys/signal.h).

       If an application is compiled with the software development
       environment set to m88kdgux or m88kdguxelf, then the siginfot style
       of signal information may be reported to the signal handler.  This
       information will normally be reported if sigaction(2) was used to
       establish the signal handler and the SASIGINFO bit is set in the
       signal action structure at the time the call was made [see
       sigaction(2)].  In this case, a pointer to an object of type
       siginfot will normally be passed as the second argument to the
       invoking signal handler, and also a pointer to an object of type
       ucontextt will be sent as the third argument [see sys/ucontext.h].
       The fields of the siginfot structure are discussed in more detail
       below.

       If, however, an application is compiled with the software development
       environment set to m88kbcs, m88kocs or m88kdguxcoff then the first
       argument available to the handler will be the caught signal number
       and a pointer to an object of type struct siginfo will always be
       available as the second argument.

       For programs that run on the Intel processor architecture, then the
       siginfo5 style of signal information may be reported to the signal
       handler.  A pointer to an object of type siginfot will normally be
       passed as the second argument to the invoking signal handler, and a
       pointer of type ucontextt will be sent as the third argument.

       A structure of type siginfo_t is also used by waitid(2) to tell a
       process why its child changed state.

       A siginfo_t structure includes the following information:

              int sisigno    /* signal number */
              int sierrno    /* error number */
              int sicode     /* signal code */

       sisigno contains the system-generated signal number.  (For the
       waitid(2) function, sisigno is always SIGCHLD.)

       If sierrno is non-zero, it contains an error number associated with
       this signal, as defined in errno.h.

       sicode contains a code identifying the cause of the signal.  If the
       value of sicode is less than or equal to 0, then the signal was
       generated by a user process [see kill(2) and sigsend(2)] and the
       siginfo structure contains the following additional information:

              pidt sipid    /* sending process ID */
              uidt siuid    /* sending user ID */

       Otherwise, sicode contains a signal-specific reason why the signal
       was generated, as follows:

       Signal    Code           Reason

       SIGILL    ILLILLOPC     illegal opcode
                 ILLILLOPN     illegal operation number
                 ILLILLADR     illegal address
                 ILLILLTRP     illegal trap
                 ILLPRVOPC     privileged opcode
                 ILLPRVREG     privileged register
                 ILLCOPROC
                 ILLBADSTK     bad stack

       SIGFPE    FPEINTDIV     integer divide by zero
                 FPEINTOVF     integer overflow
                 FPEFLTDIV     floating point divide by zero
                 FPEFLTOVF     floating point overflow
                 FPEFLTUND     floating point underflow
                 FPEFLTRES     floating point inexact result
                 FPEFLTINV     invalid floating point operation
                 FPEFLTSUB     subscript out of range

       SIGSEGV   SEGVMAPERR    address not mapped to object
                 SEGVACCERR    invalid permissions for mapped object

       SIGBUS    BUSADRALN     invalid address alignment
                 BUSADRERR     address error
                 BUSOBJERR     object error

       SIGTRAP   TRAPBRKPT     process breakpoint
                 TRAPTRACE     process trace trap

       SIGCHLD   CLDEXITED     child has exited
                 CLDKILLED     child was killed
                 CLDDUMPED     child terminated abnormally
                 CLDTRAPPED    traced child has trapped
                 CLDSTOPPED    child has stopped
                 CLDCONTINUED  stopped child had continued

       SIGPOLL   POLLIN        data input available
                 POLLOUT       output buffers available
                 POLLMSG       input message available
                 POLLERR       I/O error
                 POLLPRI       high priority input available
                 POLLHUP       device disconnected

       In addition, the following signal-dependent information is available
       for kernel-generated signals:

       Signal    Field          Value

       SIGILL    caddrt siaddraddress of faulting instruction
       SIGFPE                   (on 88k only if exception is precise)

       SIGSEGV   caddrt siaddraddress of faulting memory reference
       SIGBUS

       SIGCHLD   pidt sipid   child process ID
                 int sistatus  exit value or signal

       SIGPOLL   long siband   band event for POLLIN, POLLOUT, or POLLMSG

       For additional information about M88000 signals (including details
       about hardware exceptions, treatment of concurrent exceptions, and
       resumption of execution upon return from a signal handler), obtain
       System V Application Binary Interface: Motorola 88000 Processor
       Supplement from the 88open Consortium, and see "Signals and
       Exceptions" in Chapter 3.

SEE ALSO
       sde-target(1), sigaction(2), waitid(2), signal(5).

NOTES
       For SIGCHLD signals, if sicode is equal to CLDEXITED, then
       sistatus is equal to the exit value of the process; otherwise, it is
       equal to the signal that caused the process to change state.

       The 88open document Application Binary Interface Standards, Motorola
       88000 Processor, 88110 Addendum, Release 1.0 defines a protocol for
       protecting programs that are written for the M88100 processor but are
       running on an M88110 processor from receiving a siginfot structure
       containing misleading information.  Specifically, if an application
       that was compiled without DGUSE88110MCONTEXTANDSIGINFO defined
       is run on an M88110 processor, requests siginfot information, and
       causes an exception by executing an instruction that doesn't exist on
       the M88100 processor, then the document referred to above, in section
       5.1, requires that the siginfot pointer be passed as NULL.  The
       DG/UX system does not currently guarantee correct implementation of
       this mechanism.  That is, in some such situations, a pointer to a
       siginfot structure containing misleading information may be passed
       instead of a NULL pointer.  To obtain correct exception information
       in all cases, rebuild your program for the M88110 processor; that is,
       make sure that DGUSE88110MCONTEXTANDSIGINFO is defined during
       compilation of the module that contains the sigaction call
       establishing the relevant signal handler (m88110 implies
       DGUSE88110MCONTEXTANDSIGINFO), and write your signal handler to
       accept the revised form of exception information defined in the 88110
       Addendum document.


Licensed material--property of copyright holder(s)

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026