Subject: Re: SYS_sigaction on NetBSD ?
To: Christoph Hellwig <firstname.lastname@example.org>
From: Marc Recht <email@example.com>
Date: 01/23/2003 17:07:39
Content-Type: text/plain; charset=us-ascii; format=flowed
> You should probably just use libc's sigaction() entry point and forget
> about it's actual implementation..
The code in question is in a 3rd party app - mono. It seems they're doing=20
it because of LinuxThreads deficiencies. I've found one citation of gcc's=20
libjava (include/i386-signal.h) in their mailing-list.
/* You might wonder why we use syscall(SYS_sigaction) in INIT_SEGV and
* INIT_FPE instead of the standard sigaction(). This is necessary
* because of the shenanigans above where we increment the PC saved in
* the context and then return. This trick will only work when we are
* called _directly_ by the kernel, because linuxthreads wraps signal
* handlers and its wrappers do not copy the sigcontext struct back when
* returning from a signal handler. If we return from our divide handler
* to a linuxthreads wrapper, we will lose the PC adjustment we made and
* return to the faulting instruction again. Using syscall(SYS_sigaction)
* causes our handler to be called directly by the kernel, bypassing
* any wrappers. This is a kludge, and a future version of this handler
* will do something better. */
I guess NetBSD does "The Right Thing" and sigaction() could be my friend..
"Premature optimization is the root of all evil." -- Donald E. Knuth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (NetBSD)
-----END PGP SIGNATURE-----