[lkml]   [1996]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: SA_STACK

    > From msmith/UNIX (
    > 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


     \ /
      Last update: 2005-03-22 13:37    [W:0.018 / U:14.640 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site