Re: SA_STACK

Hemment_Mark/HEMEL_IOPS_INTERNATIONAL-SALES@uniplex.co.uk
Mon, 20 May 96 10:32:26 +0100

> 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