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. 

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)

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org