Don't install signal handler when checking cpuid

[benesch]

As part of its CPU feature detection, CryptoPP installs a SIGILL signal
handler before issuing the cpuid instruction. The intent is to
gracefully degrade on CPUs that don't support the cpuid instruction.

The problem is that it is impossible to safely overwrite a signal
handler installed by the Go runtime in go1.10 on macOS
(golang/go#22805). This causes CockroachDB 2.0 to crash on macOS Mojave:
cockroachdb/cockroach#31380.

The situation has improved on the Go front, as go1.11 makes it possible
to safely save and restore signal handlers installed by the Go runtime
on macOS.

Still, we can do better and support go1.10. There is no need to bother
installing a SIGILL handler, as the cpuid instruction is supported by
every x86-64 CPU. We can instead use conditional compilation to make
sure that we never execute a cpuid instruction on a non x86-64 CPU.

Note that CPU feature detection is performed at executable load time
(see the attribute(constructor) on DetectX86Features); therefore any
reference to function which calls DetectX86Features (notably HasAESNI)
corrupts the signal handler. It's not entirely clear why this corruption
later leads to the SIGTRAP seen in cockroachdb/cockroach#31380--is
something in macOS or the Go runtime generating a SIGILL and trying to
handle it gracefully?--but regardless, not mucking with the signal
handler fixes the issue.

[mberhault]

LGTM

[tbg]

If this is the

We can instead use conditional compilation to make
sure that we never execute a cpuid instruction on a non x86-64 CPU.

part, what's with the i386 condition?

[benesch]

Whoops, I got merge happy. cpuid is supported on x86 processors since 1993. We definitely don't care about processors before 1993, but we might someday have a 32-bit build. Seemed slightly more future proof to just proceed with cpuid on any x86 processor. ¯_(ツ)_/¯

[tbg]

Thanks!