Using sigvec & sigcontext

[Chris Torek]

In article <4549 at freja.diku.dk> seindal at skinfaxe.diku.dk (Rene' Seindal) writes:
>First of all, sigvec(2) and struct sigcontext can only be expected to exist in
>4.3BSD or 4.2BSD derived systems.

True enough.

>On 4.3BSD on Vaxen, the struct sigcontext has the same contents as a
>``jmp_buf'' (??),

Not so:

% egrep jmp_buf /usr/include/setjmp.h
typedef int jmp_buf[10];
% egrep sc\|\{\|\} /sys/h/signal.h
struct	sigvec {
};
struct	sigstack {
};
struct	sigcontext {
	int	sc_onstack;		/* sigstack state to restore */
	int	sc_mask;		/* signal mask to restore */
	int	sc_sp;			/* sp to restore */
	int	sc_fp;			/* fp to restore */
	int	sc_ap;			/* ap to restore */
	int	sc_pc;			/* pc to restore */
	int	sc_ps;			/* psl to restore */
};

As you can see, sigcontext is not an array of 10 int's.

>Even more amusing, the is an undocumented system call (no. 139) in at least
>4.3 (and 4.2) from Berkeley, Ultrix 2.0, and SunOS 3.X (and 4.0, according to
>adb.  I haven't tried), which is used by longjmp(3) to restore the saved
>context.  It takes a jmp_buf/struct sigcontext as the sole argument.  It is a
>kind of simplified sigreturn(2).  Don't look in sysent for it, since it will
>probably not be there.

139 is (was) the `sigcleanup' syscall, used in 4.2BSD to exit from
signal handlers, and indeed undocumented.  It did not take *any*
arguments; rather, it found a sigcontext structure via the user stack
pointer pushed by the `chmk' trap, an awful and bloody thing to do,
which is of course why it was fixed in 4.3BSD....

I have no idea how SunOS actually handles osigcleanup().
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris