Signal handler arguments

Signal handler arguments

[Ralf Baechle]

I'm revamping the sycall interfaces of the 64-bit Linux/MIPS kernel.  So
far the 32-bit MIPS kernel is calling all non rt-signal handlers as:

  handler(signr, 0, struct sigcontext *)

The rt-signal handlers (setup with SA_SIGINFO) get invoked as:

  handler(signr, struct siginfo *, struct ucontext *)

What do applicable standards say about the arguments passed to signal
handlers?  I'd like to settle with just the second signal handler type as
the x86-64 port seems to do but I'm a bit nervous that this might break
application code or standard compliance.

Can anybody shed light into this?  Thanks,

  Ralf

Re: Signal handler arguments

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralf Baechle wrote:

>   handler(signr, 0, struct sigcontext *)
> 
> The rt-signal handlers (setup with SA_SIGINFO) get invoked as:
> 
>   handler(signr, struct siginfo *, struct ucontext *)
> 
> What do applicable standards say about the arguments passed to signal
> handlers? 

  void (*sa_handler)(int)  What to do on receipt of signal.
  sigset_t sa_mask         Set of signals to be blocked during execution
                           of the signal handling function.
  int sa_flags             Special flags.
  void (*)(int, siginfo_t *, void *) sa_sigaction
                           Pointer to signal handler function or one
                           of the macros SIG_IGN or SIG_DFL.

- -- 
- ---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9h/uq2ijCOnn/RHQRAn6SAKCzssVnfBUo6fgiyjWJYOUTb9xSDACgnRhO
uQzkoOoA81hLw6LVvYM5vn4=
=S1W3
-----END PGP SIGNATURE-----

Re: Signal handler arguments

[Roland McGrath]

The only standards per se is what Ulrich cited.  That is, the SA_SIGINFO
signature you already have and all that's required is the first argument
for the no-SA_SIGINFO case.  So by the standards, it would always be fine
to just pass the SA_SIGINFO form.  What really matters though is existing
practice on your platform.  The traditional signature before SA_SIGINFO was
invented was (int sig, long code, struct sigcontext *) i.e. compatible
with what you cited.  For signals like SIGSEGV/SIGBUS the CODE parameter is
something useful like an address.  If it's really always been 0 on mips for
all signals, then there can't be anything expecting a useful value.
The struct sigcontext parameter might be another story.  But if you are
breaking binary compatibility with the struct sigcontext format anyway,
then you don't care.