On Dec 1, 10:06am, manu@netbsd.org (Emmanuel Dreyfus) wrote:
-- Subject: Re: psignal() and COMPAT_MACH exceptions

| Christos Zoulas <christos@zoulas.com> wrote:
| 
| > Yes, I agree with you. I think it is far too complicated. I think that
| > the question about other cases of signals that need to be delivered as
| > exceptions while they are masked still remains.
| 
| I tried to find the information from Darwin kernel sources: Let's try to
| sum it up.
| 
| We have 9 exceptions ports. Once a non dead exception port is
| registered, Mach exception should replace the signal, whatever the
| signal mask is.
| 
| 
| EXC_BAD_ACCESS: should be generated instead of SIGSEGV and SIGBUS
| EXC_BAD_INSTRUCTION: instead of SIGILL
| EXC_ARITHMETIC: instead of SIGFPE
| I would say that the 3 exception above can only be generated from a
| trap, so intercepting at trapsignal should work. I have a concern with
| SIGILL generated with psignal from sys/kern/kern_sa.c. Should they be
| turned into Mach exceptions? 
| 
| 
| EXC_BREAKPOINT: instead of SIGTRAP
| This can be generated from a trap, but also using psignal in sys_execve.
| There does not seem to be any other SIGTRAP emission from MI code.
| 
| 
| EXC_EMULATION: seems unused in Darwin
| EXC_RPC_ALERT: seems unused in Darwin
| I like unused stuff: it is easy to emulate.
| 
| 
| EXC_SYSCALL: raised on any BSD system call
| EXC_MACH_SYSCALL: raised on any Mach system call
| Thoses two one can be supported with no effort from the Darwin system
| call handler.
| 
| 
| EXC_SOFTWARE: This last exception is used in two situations
| - The softsignal feature (any signal is converted into a Mach
| exception), requested with ptrace(PT_SIGEXC, 0, 0, 0). In that
| situation, the signal mask is indeed honoured, so the right place to
| emulate the feature is in darwin_sendsignal: the exception should only
| be generated when the signal would be generated
| 
| - The following software exceptions would raise a Mach EXC_SOFTWARE
| exceptions:
| Broken pipe (usually SIGPIPE)
| Bad system call (usually SIGSYS)
| Abort (usually SIGABRT)
| These 3 signals are sent with psignal in our kernel.
| 
| I say would, because it looks so in Darwin kernel sources, but I have
| not been able to see the broken pipe and bad system call exceptions on a
| live system. The EXC_SOFTWARE port is registered, but SIGPIPE or SIGSYS
| is still sent, and the faulting process is killed by the signal. I'm
| looking for a simple idea to check for SIGABRT, but it is probably not
| implemented too.
| 
| It is worth noting that there are some ifdefs around the code for broken
| pipe, bad system call and abort exceptions: __APPLE_API_UNSTABLE. Maybe
| Apple has some plans to implement that later, no idea. I found nothing
| about SIGIO. 
| 
| 
| And a last minute good news: If I register EXC_BAD_ACCESS and try to
| kill(getpid(), SIGSEGV), I don't get a Mach exception, I get a signal. 

Even when SIGSEGV is blocked?

| This means that intercepting signals in kpsignal2 turns to be wrong, as
| we should not intercept signals sent from sys_kill. I finnally come to
| the following conclusions:
| 
| 1) SIGSEGV, SIGBUS, SIGILL, SIGTRAP and SIGFPE will be intercepted at
| trapsignal level.
| 
| 2) softsignals will be handled in darwin_sendsig. This solves the
| special case of SIGTRAP in sys_execve without the need for modifying MI
| code.
| 
| 3) We don't do anything yet for SIGPIPE, SIGSYS and SIGABRT until we
| find the need to do so (maybe on a newer MacOS X release? Anyone wants
| to check a test program on MacOS X.3? I'm working on MacOS X.2)

That sounds fine with me for now.

christos