Signal Delivery about dettrace

[gatoWololo]

This issues has been fixed. Signals are now delivered properly.

There is noticeable delay between delivering a signal and the tracee receiving the signal. Consider the program:

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

int main(){
  raise(SIGABRT);
  printf("Hello World!\n");
}

Running this program by itself aborts. But under dettrace it completes. We don't really have power to when the signal is delivered so this may be nondeterministic. We discussed a solution by:

1. Saving the state of the program
2. Jumping to the signal handler by moving the instruction pointer.

Signals may be ignored if done through ptrace. From man ptrace(2):

Restarting ptrace commands issued in ptrace-stops other than signal-delivery-stop are
not  guaranteed  to inject a signal, even if sig is nonzero.  No error is reported; a
nonzero sig may simply be ignored.  Ptrace users should not try to "create a new sig‐
nal" this way: use tgkill(2) instead.

The  fact  that  signal  injection requests may be ignored when restarting the tracee
after ptrace stops that are not signal-delivery-stops is a cause of  confusion  among
ptrace  users.

So it seems tgkill is the way to go.

[devietti]

Reopening this until we whitelist signal delivery.

Summarizing some Slack discussion here for future reference:

• Deterministic signal delivery likely requires jumping directly to the signal handler, so we can be sure when the signal is "delivered"
• Need to jump back to application code once the signal handler is done. How do we figure out when the handler is "done"? Maybe we can munge the signal stack and overwrite the return address appropriately? Also need to ensure that the app context is restored.

[gatoWololo]

As far as your second bullet point. I believe we receive a sigreturn/rt_sigreturn when the handler is done.

[rrnewton]

[this came up briefly in the call today]

@devietti - re: "jumping directly to the signal handler", is the idea that signal delivery would be instantaneous? E.g., in a sequentialized set of processes/threads, one thread sending a SIGKILL should resolve immediately before any other code runs.

Instantaneous signal delivery seems really appealing in a sequential scheduler. But, hmm, perhaps that would compromise achieving observable equivalence between a sequential scheduler and one that employs true parallelism...

[devietti]

Closing this thanks to #106, we have this working for SIGALRM.