More pid provider issues

Was tracing crisp earlier today (its running inside gdb), and noticed
a strange SIGTRAP inside the gdb. Given gdb had no breakpoints, this
shouldnt happen, and its not clear where the SIGTRAP came from.
PID provider uses SIGTRAP (breakpoint instruction) as part of its implementation
but, again this shouldnt happen.

I was pondering what might cause this - and was wondering about
signal delivery. The DTrace fasttrap provider has some acknowledgement
of signals, but am not sure I fully follow what happens, and in any
case, the code is aligned to the Solaris kernel.

Under "normal" circumstances, the PID provider puts INT3 instructions
at the probe points, and intercepts these before anything else
in the kernel sees them. There are two scenarios for
a probe - in-kernel emulation of the CPU instruction (for instructions
which modify the PC), or, trampolining in user space whereby
a copy of the original instruction is executed from a temporary buffer.

Consider the following simple program:

#include <stdio.h>
#include <signal.h>

volatile unsigned cnt;
int     tick;

void alarm_handler()
{
        printf("tick: %2d %u\n", tick++, cnt);
}
int main(int argc, char **argv)
{
        while (1) {
                int     old_tick = tick;
                signal(SIGALRM, alarm_handler);
                alarm(1);
                for (cnt = 0; ; cnt++) {
                        if (tick != old_tick)
                                break;
                }
        }
}

It sits, counting for duration of 1s, and then prints the count.
We use the alarm clock signal to do the printing. Not a strictly
ISO-C compliant program, but good enough.

If I use the pid provider to trace this, all is good until the alarm_handler
returns from the signal. I need to debug what happens here.

Out of curiosity, I tried this on MacOS, and, surprisingly, the application
terminates erratically. Theres no core dump. gdb tells me the exit code
is 0170 (presumably a signal was delivered). The tail end of the dtrace is

  0  37727                 alarm_handler:37
  0  37728                 alarm_handler:38
  0  37711             alarm_handler:return
  0  37728                 alarm_handler:38
  0  37711             alarm_handler:return
  0  37708                         start:34
  0  37709                         start:36
  0  37756               stub helpers:entry

So, I wander how thoroughly the PID provider is tested and actually
*used*.

Post created by CRiSP v11.0.10a-b6436