Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: What is sigcleanup?
Message-ID: <10001@dog.ee.lbl.gov>
Date: 18 Feb 91 10:08:58 GMT
References: <1991Jan22.153802.9869@daimi.aau.dk> <119782@uunet.UU.NET>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 34
X-Local-Date: Mon, 18 Feb 91 02:08:58 PST

>In article <1991Jan22.153802.9869@daimi.aau.dk> kaja@daimi.aau.dk
>(Kaja P. Christiansen) writes:
>>What is "sigcleanup" doing?

In article <119782@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
>I dunno for sure, but I'll hazard a guess. It could be a mutation of
>4.3BSD's sigreturn call with new bells and whistles. ...

This is almost exactly backwards.

4.2BSD had an undocumented almost-but-not-quite-system-call (#139)
called (internally) sigcleanup().  The reason I call it an `almost-
but-not-quite-system-call' is the following, found near the top of
/sys/vax/trap.c's syscall() function in 4.2BSD:

	u.u_ar0 = locr0;
	if (code == 139) {			/* XXX */
		sigcleanup();			/* XXX */
		goto done;			/* XXX */
	}
	params = (caddr_t)locr0[AP] + NBPW;

The code at `done' handled the case where a regular system call was
all done and needed to return, having already changed r0 (and possibly
r1) and set the PSL condition codes.  Naturally, returning from a
signal should not set r0 or the PSL to `successful return from signal'
since the signal may have occurred while r0 or the condition codes
were in use for something else.

sigcleanup has since been replaced with sigreturn, which rbj has
already described.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov