Re: sigaltstack setting and RT signal handlers

[Paul Mackerras <paulus at samba dot org>]

Ulrich Drepper writes:

> > Is it reasonable to expect that a signal handler can
> > change the sigaltstack setting of the process by altering
> > ucp->uc_stack?
> 
> It's not documented but I would not bet that nobody uses this.  It's
> exposed in a data structure which contains other elements which are
> indeed modified by applications.
> 
> I don't say this cannot be changed.  Doing something as stupid as
> modifying uc_stack deserves to be punished.  But I won't make the decision.

What I am wondering is why uc_stack was ever used to store the
_alternate_ stack in the first place.  The POSIX description of
uc_stack is "the stack used by this context".  So I would have thought
that if anything, ucp->uc_stack should describe the current stack at
the time the signal was delivered.

What do other OSes do with uc_stack on signal delivery?

> > Likewise, is it reasonable to expect that a signal handler can change
> > the register values of the interrupted context by altering
> > ucp->uc_mcontext?
> 
> Of course.  There is quite a bit of code out there depending on this.

But the format of uc_mcontext and the precise effect of changing it is
implementation-dependent, no?

What I want to do is to extend the mcontext on PPC to include space
for the altivec registers.  But I only want to save and restore the
altivec register values in processes which have actually used the
altivec unit.  So I thought I would have a bit in the mcontext which
says whether the altivec register values in the mcontext are valid or
not.  If a signal handler wants to alter the altivec register values
and the valid bit is clear (which would only happen if the process has
never used the altivec unit) then it should clear the altivec register
values and set the valid bit before making the modifications.  Does
that sound reasonable?

Paul.