Subject: Re: SYS_sigaction on NetBSD ?
To: Christoph Hellwig <hch@infradead.org>
From: Marc Recht <marc@informatik.uni-bremen.de>
List: tech-kern
Date: 01/23/2003 17:07:39
--==========877320887==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
> 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..
Regards,
Marc
--
"Premature optimization is the root of all evil." -- Donald E. Knuth
--==========877320887==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (NetBSD)
iD8DBQE+MBNL7YQCetAaG3MRArmzAJ9HicYxpTeFLDaSncNoyM1Mi/OVVgCggNXo
qm9PzJ7pj8Z7aOrABiQL7bM=
=YDFn
-----END PGP SIGNATURE-----
--==========877320887==========--