Messages in this thread | | | From | Hemment_Mark/ | Date | Mon, 20 May 96 15:31:42 +0100 | Subject | Re: SA_STACK |
| |
> From: msmith/UNIX (msmith@quix.robins.af.mil) > Date: ## 05/20/96 12:42 ## > Well I started hacking at it and I've sent some diffs to Linus > which are wrong but they are no worse than the code that was there. > Basically the problem I'm having is not implementing sigstack() or > sigaltstack() structs or calls but how to handle things like a > longjmp() out of a signal handler which is currently on an alt stack, > or a calling a signal handler from a signal handler. This could > be an easy fix if I had a stack_size field. With sigstack() that is > not possible since the stack is malloced but the struct doesn't > contain the size. sigaltstack{} however requires a ss_ssize(sp) field.
> Maybe it would be better to forget the BSD style sigstack() and go > with the SYSV sigaltstack() ?
> -Melvin
I prefer the SVR4 implementation, with the reasoning that I have never used BSD's sigstack(). POSIX.2/XPG4 didn't tackle alternative stacks, but someone should check up what the current working groups are doing - there might well be in a new draft that covers this.
Are you not sure of how to code setjmp()/sigsetjmp, or what they should do? setjmp() and sigsetjmp() are usually defined as saving the 'stack environment' - this sounds like _which_ stack as well, and I guess this is what you are doing. I assume SVR4 systems build these library routines upon getcontext(). This call uses a 'struct ucontext' which allows the current stack to be fetched. If you go with SVR4 I would recommend implementing the setcontext()/ getcontext() system call pair to build *jmp() with (and they are system calls, not library routines - or were that last time I looked).
Also note, that a SIGSEGV due to the maximum stack size changes slightly in behaviour if there is an alternative stack - can't remember how...
Nested signal handlers could be problem under Linux, which (again, if I remember correctly - havn't got access to code at work) builds stack frames for _all_ pending signals at once. This may help performance but is ignoying in not allowing signal handlers to install different handlers for pending signals. Anyway, under SVR4, the kernel switches to the alternative stack if the signal being delievered is marked as being SA_NOSTACK _and_ the current stack is not the alt-stack. This next bit needs checking by someone with good doc - or access to a machine to test the theory - but I believe the kernel only switches back to the 'main' stack when _all_ the alternative-stack signal handlers have returned. This means, that while a process is servicing a signal delievered on the alt-stack, all other signals (whether installed SA_NOSTACK or not) are also delievered on the alt-stack. Someone, please put me right if I've got this wrong!
Finally, before delievering a sig on the alt-stack, check there is enough space first, and post a SIGSEGV on the main stack if there isn't. This won't ensure the stack won't overflow, but would be a help in debugging the overflow (espically if we had SA_SIGINFO!).
Hmm.., just had a thought. It would be easier to implement user- level threads if setjmp() didn't restore which stack....I need to get on a true SVR4 box and check this out.
markhe
| |