In article <1g4zr8d.zqnayv1xq0i4zM%manu@netbsd.org>,
Emmanuel Dreyfus <manu@netbsd.org> wrote:
>Hi
>
>In the wonderful world of MacOS X, signals can be replaced by
>exceptions. Exceptions are Mach messages sent to a process to notify an
>exceptionnal condition.
>
>For instance, when gdb traces a program, it does not wait for signals,
>it waits for Mach messages. This makes my job a bit complicated, but
>fortunately, trapsignal() can be emulation specific already. I just
>intercept signals at trapsignal() level I and transform them into
>exception, if the tracer process required so. The code for this already
>exists and it works. 
>
>I have one special problem with the SIGTRAP emission in
>sys/kern/kern_exec:sys_execve(), for traced processes. It is currently
>done with psignal(), which offers no hook for emulations. What about the
>following patch?
>
>Index: kern_exec.c
>===================================================================
>RCS file: /cvsroot/src/sys/kern/kern_exec.c,v
>retrieving revision 1.176
>diff -U4 -r1.176 kern_exec.c
>--- kern_exec.c 17 Nov 2003 22:52:09 -0000      1.176
>+++ kern_exec.c 25 Nov 2003 17:03:47 -0000
>@@ -764,10 +764,20 @@
>        /* map the process's signal trampoline code */
>        if (exec_sigcode_map(p, pack.ep_es->es_emul))
>                goto exec_abort;
> 
>-       if (p->p_flag & P_TRACED)
>+       if (p->p_flag & P_TRACED) {
>+#ifdef __HAVE_SIGINFO
>+               ksiginfo_t ksi;
>+
>+               KSI_INIT_TRAP(&ksi);
>+               ksi.ksi_signo = SIGTRAP;
>+               ksi.ksi_trap = TRAP_TRACE;
>+               (*p->p_emul->e_trapsignal)(l, &ksi);
>+#else
>                psignal(p, SIGTRAP);
>+#endif
>+       }
> 
>        free(pack.ep_hdr, M_EXEC);
>
>My concern is that I'm using trapsignal for a signal sent from somewhere
>else than a trap. Is it a serious problem?

I don't think it is a serious problem in this case. I think that the
else case, should be:
		(*p->p_emul->e_trapsignal)(l, SIGTRAP, 0);
You should put a comment on top, explaining why you are calling trapsignal
here.

>Additionnaly, should we include more information with siginfo for this
>event? 

I don't think we have any more info do we?

christos