Re: why do we put code onto the stack when doing a signal?

Mike Jagdis (
Tue, 15 Apr 1997 10:49:17 +0100 (GMT/BST)

On Mon, 14 Apr 1997, Mark Hemment wrote:

> There is one catch.
> When SA_SIGINFO is implemented, we can have a different number of
> arguments on the stack-frame for a signal handler. (SA_SIGINFO adds two
> extra arguments, a "siginfo_t *" and "ucontext_t *" - I must find time to
> do this...).

If you do it please try and make it compatible with other Unix
flavours. SCO OS5 at least implements SA_SIGINFO on "standard"
signals (it doesn't have extended real time signals or queued
signals according to my tests). It would be a complete bugger
to have to try and reimplement signal handling in iBCS :-).

> A libc signal return function would need to act as the signal-handler
> caller, which can be difficult as it wouldn't know how may args are on the
> stack.

The "standard" handler has (int, sigcontext) where sigcontext is
a Linux extension. The POSIX handler is (int, siginfo, sigcontext).
We could just use the three argument version for everything at
the expense of having to recompile things like dosemu and wine
that use the hidden sigcontext data. The alterative might be to
have the signal frame building code set the return to be either
sigreturn1 or sigreturn2 depending whether it was placing a
siginfo struct or not.

The better solution (IMHO) is to always deliver siginfo. It only
breaks a few non-portable applications anyway and the alternative
is increased complexity and bloat.


|  Mike Jagdis                  |  Internet:   |
|  Roan Technology Ltd.         |                                      |
|  54A Peach Street, Wokingham  |  Telephone:  +44 118 989 0403        |
|  RG40 1XG, ENGLAND            |  Fax:        +44 118 989 1195        |