Audit signal safety for vsyscall hooks

[joneschrisg]

Back when we were wrapping libc functions, we only had to worry about POSIX safety requirements. But now we're interposing on raw syscalls. Seen while debugging #217.

This gets a bit tricky because we can't make all the syscalls require async-signal-safety, or else we'll never be able to initialize syscallbuf. The solution might be to somehow detect a safe init point from the tracer and do the work there.

Need a workable solution for 0.4.

[joneschrisg]

So I think making all the hooks async-signal-safe is the only sane way to maintain this code. Here's how I see this working

• remove implicit process init. That's useless because the vsyscall hooks don't get called until after process init.
• have the .so constructor function do process init, assuming it's the only thread (enforced by rr tracer, can revisit as needed). No async-signal-safety needed from that context.
• have the constructor function initialize the main thread's buffer.
• restore pthread_create() wrapper, but have the trampoline only initialize the new thread's buffer. Another context that doesn't require async-signal-safety.
• remove implicit thread initialization.

In that scheme, initialization is only done from no-signal-safety contexts. All of the hooks themselves are already async-signal-safe (except for implicit init, which dies here).

The two downsides/TODOs are

• assuming ctor function does process init (which we already do, and check)
• can't buffer syscalls from children created by direct clone() calls. Possibly important in the future for rust or go or hipster things like that. Not that we support direct clone() anyway ... and hm, I wonder what would happen if a tracee attempted that ...

[joneschrisg]

Now that task cleanup is done in rr, we don't need to load the preload lib in the child. So we can go back to the clearer name and simplify the impl a bit.