Subject: sgi sigaction (fwd)
To: None <tech-kern@netbsd.org>
From: Ron Minnich <rminnich@mini.sarnoff.com>
List: tech-kern
Date: 11/27/1994 15:37:40
the asked me to forward this discussion of sgi sigaction support. Much 
better than sunos and of course more useful than posix. I think it's the 
right model for netbsd.

rno

---------- Forwarded message ----------
Date: Wed, 23 Nov 1994 16:51:05 +30000
From: Ron Minnich <rminnich@mini.sarnoff.com>
To: Chuck Cranor <chuck@maria.wustl.edu>, Theo Deraadt <deraadt@fsa.ca>,
    jtc@sun-lamp.cs.berkeley.edu, pk@sun-lamp.cs.berkeley.edu
Subject: sgi sigaction

sgi has the normal svr4 sigaction. This is basically useless for what i 
do, but fortunately sgi has an extended sigaction, invoked with the 
SA_SIGINFO flag in the sigaction struct in the flags field. 

The extended version gives you the following: 

" .. If set and the signal is caught, sig is passed as the first argument to
the signal-catching function.  If the second argument is not equal to NULL,
it points to a siginfo_t structure containing the reason why the signal was
generated [see siginfo(5)]; the third argument points to a ucontext_t
structure containing the receiving process's context when the signal was
delivered [see ucontext(5)] ... " 

So how do i use this? well on sgi the siginfo contains: 
typedef struct siginfo {
        int     si_signo;               /* signal from signal.h */
        int     si_code;                /* code from above      */
        int     si_errno;               /* error from errno.h   */
        union {

                int     _pad[SI_PAD];   /* for future growth    */

                struct {                        /* kill(), SIGCLD       */
                        pid_t   _pid;           /* process ID           */
                        union {
                                struct {
                                        uid_t   _uid;
                                } _kill;
                                struct {
                                        clock_t _utime;
                                        int _status;
                                        clock_t _stime;
                                } _cld;
                        } _pdata;
                } _proc;                        

                struct {        /* SIGSEGV, SIGBUS, SIGILL and SIGFPE   */
                        caddr_t _addr;          /* faulting address     */
                } _fault;

                struct {                        /* SIGPOLL, SIGXFSZ     */
                /* fd not currently available for SIGPOLL */
                        int     _fd;    /* file descriptor      */
                        int     _band;
                } _file;
#if ((defined(_POSIX_4SOURCE) || defined(_SGI_SOURCE)) && !defined 
(_XOPEN_SOURCE))
                union sigval    _value;
#define si_value        _data._value
#endif

        } _data;

} siginfo_t;

so the siginfo tells you the signal, code, errno, and extended 
information about the signal not available any other way. This could 
easily fit netbsd right now. no machine-dependent stuff here that i can 
see. For my case i can get the address easily. 

The ucontext is more involved ... 
typedef struct ucontext {
        unsigned long   uc_flags;
        struct ucontext *uc_link;
        sigset_t        uc_sigmask;
        stack_t         uc_stack;
        mcontext_t      uc_mcontext;
        int             uc_triggersave; /* SGI: state of graphic trigger 
*/
        long            uc_filler[48];
} ucontext_t;

don't let the small size fool you. Basically all the stack barf is in here.
On the sgi i can easily figure out the kind of trap (write or read fault) or
whatever else i need. On the 386, ucontext would include the current
sigcontext PLUS the cr* registers. On the sparc, it would be trapframe +
enough bits to tell me what really happened, not just the 'code' value. On
the 68k, i assume the 68k trapframe. 

Just plugging in the sunos style info is not really enough, at least for 
what i do. It's adding one field (addr) which is not in itself 
sufficient. I like the sgi approach; you get all you need, with nothing 
stripped out. VERY useful. 

ron