Thread takeover on attach fails b/c SIGUSR2 is blocked: switch to another signal?

[derekbruening]

Attaching (via ptrace #38 or for statically-linked DR) to a process that has masked most non-fatal signals fails to take over the rest of the app threads. We could try to use ptrace to take them over but that is difficult for the static-link case. Or we could switch from SIGUSR2 to a signal less likely to be masked, like SIGFPE. We would distinguish from a synchronous signal by looking at si->code (set as far back as 2.2 kernel; some other siginfo fields were unreliable back then but not this one) and other fields.

E.g., this is hit attaching to mysqld, which blocks all non-fatal signals. The ptrace attach succeeds but then DR's takeover times out and fails.

[derekbruening]

Unfortunately it's looking like QEMU does not handle DR sending SIGFPE via SYS_kill: it just crashes right up front.

• SIGSEGV and SIGBUS are harder b/c DR looks for crashes with those.
• SIGABRT is used asynchronously already and so harder to distinguish from
  the app: though that's true of SIGUSR2 too so it's a candidate.
  I see some suspect code looking for it in core/unix/os.c.
• SIGILL is already used for nudges and init-time.
• SIGTRAP??

Could try:

• SIGSTKFLT ("Stack fault on coprocessor (unused)"): not there on Mac.

Maybe the best thing is to change it from a compile-time constant to a
runtime variable controlled by an option so it can be adjusted for
different circumstances.

[derekbruening]

I think it is a little too complex to have a runtime option-controlled signal with all the constraints: going to go with hardcoded SIGSTKFLT on Linux and SIGFPE on Mac for now.