Xref: utzoo comp.unix.questions:12512 comp.unix.wizards:15277
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!kth!enea!dkuug!freja!skinfaxe!seindal
From: seindal@skinfaxe.diku.dk (Rene' Seindal)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re^2: Using sigvec & sigcontext
Message-ID: <4557@freja.diku.dk>
Date: 28 Mar 89 01:30:32 GMT
References: <331@h.cs.wvu.wvnet.edu> <4549@freja.diku.dk> <16542@mimsy.UUCP>
Sender: news@freja.diku.dk
Lines: 74

chris@mimsy.UUCP (Chris Torek) writes:

> In article <4549@freja.diku.dk> seindal@skinfaxe.diku.dk (Rene' Seindal) writes:

> >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.

I hate to argue with you.  You are right too often :-)

I said same contents, not same type.  A close look at setjmp will reveal that
is only uses the first seven longwords of the jmp_buf, for exactly the values
shown above.  A comment even says "# construct sigcontext"!  jmp_buf is
probably only declared as an array, so people don't have to take the address
themselves. (I am looking in MORE/bsd sources from Mt. Xinu, marked
"@(#)setjmp.s	5.5 (Berkeley) 3/9/86").

> >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....

You are right about the argument passing.  It does, however, look the same
from user code.  Code like

	pushl	<addr of sigcontext or a jmp_buf>
	chmk	$139

will do a longjmp (without restoring register contents, as 4.[23] longjmp does).

Syscall 139 still exists in the 4.3 I use (MORE/bsd), even though it isn't
listed in sysent.  Look in the top of syscall().  That is an awful and bloody
thing to do too.  Was it left in only because of longjmp(), which is able to
use sigreturn() instead (more awful and bloody code), or because other
programs depended on it (even more awful and bloody)? 

> I have no idea how SunOS actually handles osigcleanup().

I haven't got sources to SunOS 4.0, but it look like it uses the 4.2 scheme.
It has sigcleanup listed as syscall 139 in sysent, taking no arguments.  The
code for sigcleanup looks similar, fetching a sigcontext pointer from the user
stack, followed by a copyin of the necessary parts of the sigcontext, and
assignment to the saved registers in the user structure.  SunOS hasn't got
sigreturn either, so those parts of the kernel might be from 4.2.

Rene' Seindal (seindal@diku.dk).