Emmanuel Dreyfus <manu@netbsd.org> wrote:

> Conclusion: I can avoid the sigfilter hook at the beginning of kpsignal2 if
> I install another hook to avoid the SIGCHLD to the parent and process stop
> each time a traced process get a signal.

I made a new discovery when I tried to implement the PT_THUPDATE
command of Darwin's ptrace.
 
They use PT_THUPDATE to set p->p_xstat and to add the signal to
p->p_sigctx.ps_siglist. gdb calls ptrace with PT_THUPDATE to let signals
passing through its traced process or to discard them.

If I use the hook at the beginning of kpsignal2 (which is currently what
is done), it executes in the context of the signal sender. I have to
remotely suspend the thread that raised the exception and send the
exception message to the catcher. Then I return. I need to know
immeditatly if a UNIX signal should be sent or not, I cannot wait for
the exception message reply, blocking the message sender (it can be the
kill command, for instance)

It's the catcher that decides with PT_THUPDATE if there should be an
UNIX signal or not. It will call PT_THUPDATE and it then send a reply
message to the exception to let the faulting thread continue. When the
kernel receive this message, it has to unblock the faulting thread, and
then possibly avoid sending the signal. With a hook at the beginning of
kpsignal2, it is too late, the sender has gone out of the hook and it is
not possible to choose if the signal should be inhibited or not.

Therefore the hook has to be in issignal. I tried this with various test
cases and it seems to emulate correctly any Mach exception usage I can
try. Therfore I'll commit that change shortly.  

-- 
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