Messages in this thread |  | | From | Hemment_Mark/ | Date | Mon, 20 May 96 10:32:26 +0100 | Subject | Re: SA_STACK |
| |
> From msmith/UNIX (msmith@quix.robins.af.mil) > Date: ## 05/17/96 19:26 ## > In the current kernel there is potential for supporting the > sigaltstack() call, and struct sigaction contains an obsolete > field (sa_restorer) which could probably be changed to something > like sa_sigaltsp. Shouldn't this be moved out into the kernel > task_struct because according to the definition of sigaltstack() > the signal stack is not per sig-handler but 1 per process, even > though sigaltstack() can be called multiple times.
Yep, that sounds right. The comment in ./include/asm/signal.h about using the sa_restorer field seems wrong to me also.
> Am I wrong about this?
> In any case, what would be the side effects? There is no sigaltstack() > in libc 5.3.12 as far as I can see so I dont see a problem with patching > it. I do see alternate stack stuff in elfcore struct elf_prstatus but > it is #if 0, (waiting for someone to imp? :) )
I haven't got any POSIX.2/XPG4 doc here, but I feel sure it would effect sigsetjmp()/siglongjmp() (restoring to the required stack), and getcontext()/setcontext() in the SVIDIII universe. I don't know ELF (can anyone recommend a good book - online doc), but can't think why it would need any support for an alt-stack (maybe for core dumps?). gdb would need to have support.
Isn't there a group working on real-time signals? Hopefully, alternative stacks (and SA_SIGINFO (sp?)) will come out of this work.
> -Melvin
markhe
|  |