fit what it does.
The softsignal feature is used in Darwin to trace processes. When the
traced process gets a signal, this raises an exception. The debugger will
receive the exception message, use ptrace with PT_THUPDATE to pass the
signal to the child or discard it, and then it will send a reply to the
exception message, to resume the child.
With the hook at the beginnng of kpsignal2, we are in the context of the
signal sender, which can be the kill(1) command, for instance. We cannot
afford to sleep until the debugger tells us if the signal should be
delivered or not.
Therefore, the hook to generate the Mach exception must be in the traced
process context. That was we can sleep awaiting for the debugger opinion
about the signal, this is not a problem. The hook is hence located into
issignal, at the place where normally SIGCHILD is sent to the debugger,
whereas the traced process is stopped. If the hook returns 0, we bypass
thoses operations, the Mach exception mecanism will take care of notifying
the debugger (through a Mach exception), and stop the faulting thread.
Exceptions coming from a trap are generated from darwin_trapsignal()
softsignals are from darwin_sigfilter(), a function that is called
from darwin_trapsignal() and from kpsignal2() [the latter from a
emulation specific hook which is not yet committed]
Make some sanity checks to avoid sending data to a port with no receiver.
See http://mail-index.netbsd.org/tech-kern/2003/12/01/0008.html and
follow-ups for details.
may turn into exceptions on Mach: a small message sent by the kernel to
the task that requested the exception.
On Darwin, when an exception is sent, no signal can be delivered.
TODO: more exceptions: arithmetic, bad instructions, emulation, s
software, and syscalls (plain and Mach). There is also RPC alert, but
I have no idea about what it is.
While we are there, remove some user ktrace in notification code, and add
a NODEF qualifier in mach_services.master: it will be used for notifications
and exceptions, where the kernel is always client and never server: we
don't want the message to be displayed as "unimplemented xxx" in kdump (thus
UNIMPL is not good), but we don't want to generate the server prototype
(therefore, STD is not good either). NODEF will declare it normally in the
name tables without creating the prototype.
