Subject: Re: SYS_sigaction on NetBSD ?
To: Christoph Hellwig <>
From: Marc Recht <>
List: tech-kern
Date: 01/23/2003 17:07:39
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..


"Premature optimization is the root of all evil." -- Donald E. Knuth
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

Version: GnuPG v1.2.1 (NetBSD)