I'm not sure how/why the previous code was working (I guess we weren't running into error codes very often), but I found that it wouldn't work properly when errors (such as EINTR) occurred. The issue was that `kevent64` is the libc wrapped version of the call that returns its error codes in `errno`, so we were only getting `-1` for all errors, and then our own libc wrapper was translating that into EPERM in our errno return. What we actually want is the raw error value, so we have to use `sys_kevent64` directly.
We basically have to reimplement locking, memory allocation, and TLS for xtrace directly on top of Linux syscalls because it can't use almost anything external (it can pretty much only use libsystem_kernel).
The one exception is that we use `pthread_key`s from libpthread to make TLS easier to implement. The only side effect that has is that it's one less available key for the application we're tracing to use, but we shouldn't ever see that cause problems (and if we do see it cause problems later on, then we can revise that).
This fixes the symbol linking issue for `_os_alloc_once_table`, allowing us to remove our workaround (this hopefully fixes an issue with Bash freezing up when forking).
This was causing issues with Homebrew due to Ruby using `_mach_boottime_usec` (indirectly), which repeatedly does `kern.boottime` sysctls until two results match.
I'm not quite sure why we used to always create our own kqueue, but that could cause all sorts of issues. For example, if the user decided to add events via a different kevent call and then use kevent_qos to poll, they wouldn't get any events because we're actually listening to a different kqueue. Another example: since the kqueue was always shared between kevent_qos calls, different kqueue fds called on kevent_qos would all operate on the same kqueue.
Of course, in the `kq=-1` case, we still perform the correct behavior of using our default kqueue. But if the user gave us a kqueue, let's use it.
macOS and BSD make sockets created from `accept` inherit the listening socket's O_NONBLOCK flag (and maybe some others, but that requires further testing).
The comment pretty much explains it: we need to make sure we have enough space for the vchroot path fixup. This was causing segfaults when trying to use Unix sockets sometimes (consistently reproducible with the Mio test suite's Unix socket tests).
