dymm@b.cs.wvu.wvnet.edu (David Dymm) (03/20/89)
A quick question concerning "sigvec".
The UNIX manual shows the user's interrupt handler as:
handler (sig, code, scp)
int sig, code;
struct sigcontext *scp;
According to the manual:
"Scp is a pointer to the sigcontext structure used to restore
the context from before the signal."
So how do I use "scp"???
Can I use it to explicitly restore the context to return where I
was before the signal?
If so, then I should be able to store it somewhere for later use,
then use it at some time in the future to go back to where I was
before the signal occurred. Does this make sense?
David Dymm Software Engineer
USMAIL: Bell Atlantic Knowledge Systems,
145 Fayette Street, Morgantown, WV 26505
PHONE: 304 291-9898 (8:30-4:30 EST)
USENET: {allegra,bellcore, cadre,idis,psuvax1}!pitt!wvucsb!dymm
INTERNET: dymm@b.cs.wvu.wvnet.eduaida@porthos.csl.sri.com (Hitoshi Aida) (03/21/89)
In article <331@h.cs.wvu.wvnet.edu> dymm@b.cs.wvu.wvnet.edu (David Dymm) writes: >So how do I use "scp"??? > >Can I use it to explicitly restore the context to return where I >was before the signal? In general, no. You should do a simulated "return from the interrupt" to restore the context. It includes restoring registers (including stack pointer and program counter), switching stack (if running on sigstack) and restoring signal mask, all in an atomic operation. That can be done only by returning from signal handler. You can more or less simulate it using assemby code, but some race condition cannot be avoidable. >If so, then I should be able to store it somewhere for later use, >then use it at some time in the future to go back to where I was >before the signal occurred. Does this make sense? No. The sigcontext points to a position in the stack which will no longer available after returning from the signal handler. You can use it only within the signal handler. At least you can modify the signal mask, program couner and status register field of the sigcontext, and they will take effect upon return from the signal handler. -------- Hitoshi AIDA (aida@csl.sri.com) Computer Science Laboratory, SRI International
sarnila@tukki.jyu.fi (Pekka Sarnila) (03/22/89)
In article <9358@cslb.CSL.SRI.COM> aida@csl.sri.com (Hitoshi Aida) writes: >In article <331@h.cs.wvu.wvnet.edu> dymm@b.cs.wvu.wvnet.edu (David Dymm) writes: >>Can I use it to explicitly restore the context to return where I >>was before the signal? >In general, no. You should do a simulated "return from the interrupt" >>If so, then I should be able to store it somewhere for later use, >>then use it at some time in the future to go back to where I was >>before the signal occurred. Does this make sense? >No. The sigcontext points to a position in the stack which will no longer Sorry if this off the line but I didn't see the original posting. What actually are you trying to do before continuing from the point where signal took place that you can't do from the signal handler? Are you intending to return twice or what? Maybe you could use a fork-wait within the handler, let the child return from handler and after you're done with what you wanted, let the child exit, and the original handler will return. -- ------------------------------------------------------------------- Pekka Sarnila, University of Jyvaskyla Finland sarnila@tukki.jyu.fi -------------------------------------------------------------------
seindal@skinfaxe.diku.dk (Rene' Seindal) (03/24/89)
dymm@b.cs.wvu.wvnet.edu (David Dymm) writes: > A quick question concerning "sigvec". > The UNIX manual shows the user's interrupt handler as: > handler (sig, code, scp) > int sig, code; > struct sigcontext *scp; > According to the manual: > "Scp is a pointer to the sigcontext structure used to restore > the context from before the signal." > So how do I use "scp"??? First of all, sigvec(2) and struct sigcontext can only be expected to exist in 4.3BSD or 4.2BSD derived systems. 4.3BSD from Berkeley (or Mt. Xinu) has a sigreturn(2) systemcall, which allows you to return from a signal handler, using a specified sigcontext. It could probably be used to implement coroutine-like features. On 4.3BSD on Vaxen, the struct sigcontext has the same contents as a ``jmp_buf'' (??), so on such a system you can call sigreturn with a jmp_buf (made with setjmp(3)) og call longjmp(3) with a sigcontext (as passed to a signal handler). This is undocumented and implementation-defined, so you probably wouldn't want to use it. 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. I guess the conclusion to all this is that you don't use scp. Rene' Seindal (seindal@diku.dk).
chris@mimsy.UUCP (Chris Torek) (03/26/89)
In article <4549@freja.diku.dk> seindal@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@mimsy.umd.edu Path: uunet!mimsy!chris