Subject: Re: SIGTRAP for traced processes and COMPAT_MACH
To: None <>
From: Christos Zoulas <>
List: tech-kern
Date: 11/25/2003 19:32:28
In article <>,
Emmanuel Dreyfus <> wrote:
>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);
>                psignal(p, SIGTRAP);
>+       }
>        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

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

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