kaja@daimi.aau.dk (Kaja P. Christiansen) (01/22/91)
In the process of debugging a perl program, I used "trace" and noticed that "trace" repeatedly showed calls to "sigcleanup" (which occasionally looped). Searching for "sigcleanup" in perl and C libraries (and manual pages as well) did not give any explanation of "sigcleanup", except that: 1) entry #139 in /usr/include/sys/syscall.h is unused. 2) "strings /usr/bin/trace" shows sigcleanup as placed between "utimes" and "adjtime" (#138 and #140 respectively). What is "sigcleanup" doing? We use sun3, SunOS 4.0.3, perl 3.44. -- Kaja P. Christiansen Computer Science Department (kpchristiansen@daimi.aau.dk) Aarhus University Phone: +45 86 12 71 88 Ny Munkegade 116, Fax: +45 86 13 57 25 DK-8000 Aarhus C., Denmark
rbj@uunet.UU.NET (Root Boy Jim) (01/25/91)
In article <1991Jan22.153802.9869@daimi.aau.dk> kaja@daimi.aau.dk (Kaja P. Christiansen) writes: >What is "sigcleanup" doing? 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. RTFM sez "sigreturn allows users to atomicly unmask, switch stacks, and return from a signal context". Since signals are more complex than they used to be, s system call is required to exit from them as well as to enter them. When a signal handler returns, it executes what is known as the signal trampoline code, which actually calls sigreturn. Setjmp/longjmp have been extended to save and restore the signal mask as well. However, _setjmp/_longjmp exist for speedier execution when signals are involved. Now sing with me to the tune of a Beatles song: We all live in a signal trampoline, A signal trampoline, a signal trampoline! >Kaja P. Christiansen Computer Science Department >(kpchristiansen@daimi.aau.dk) Aarhus University >Phone: +45 86 12 71 88 Ny Munkegade 116, >Fax: +45 86 13 57 25 DK-8000 Aarhus C., Denmark -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
francus@e2big.mko.dec.com (Yoseff Francus) (01/29/91)
In article <119782@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >In article <1991Jan22.153802.9869@daimi.aau.dk> kaja@daimi.aau.dk (Kaja P. Christiansen) writes: >>What is "sigcleanup" doing? > sigcleanup is called after the user written signal handler is finished. A chmk $139 is done. This puts you into syscall(...) In syscall there is an explicit check for 139 and a call to sigcleanup. It resets the kernel stack so that you eventually return to the point in you program where you made the system call which later checked for pending signale which then dod the signal trampoline stuff and so on. The above is completely true for a VAX, your mileage will vary on other architectures. -- In Xanadu did Kubla Khan A stately pleasure dome decree But only if the NFL To a franchise would agree francus%metsny.mko.dec.com@decwrl.dec.com
torek@elf.ee.lbl.gov (Chris Torek) (02/18/91)
>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