* Signal handler arguments
@ 2002-09-17 20:20 Ralf Baechle
2002-09-17 21:06 ` Ulrich Drepper
0 siblings, 1 reply; 3+ messages in thread
From: Ralf Baechle @ 2002-09-17 20:20 UTC (permalink / raw)
To: libc-hacker
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Signal handler arguments
2002-09-17 20:20 Signal handler arguments Ralf Baechle
@ 2002-09-17 21:06 ` Ulrich Drepper
2002-09-17 22:15 ` Roland McGrath
0 siblings, 1 reply; 3+ messages in thread
From: Ulrich Drepper @ 2002-09-17 21:06 UTC (permalink / raw)
To: Ralf Baechle; +Cc: libc-hacker
-----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-----
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Signal handler arguments
2002-09-17 21:06 ` Ulrich Drepper
@ 2002-09-17 22:15 ` Roland McGrath
0 siblings, 0 replies; 3+ messages in thread
From: Roland McGrath @ 2002-09-17 22:15 UTC (permalink / raw)
To: Ralf Baechle; +Cc: libc-hacker
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-09-18 5:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-17 20:20 Signal handler arguments Ralf Baechle
2002-09-17 21:06 ` Ulrich Drepper
2002-09-17 22:15 ` Roland McGrath
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).