WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/gnu/llvm/lib/Target?h=jd%2Fqueueboosts 2020-06-04T22:33:17Z 2020-06-04T22:33:17Z gkoehler gkoehler@openbsd.org 2020-06-04T22:33:17Z urn:sha1:21ddc59af3b7bf4d9a666653828d7e9ee41cba12 32-bit PowerPC doesn't have instructions for lock-free atomic ops on 8-byte values, and needs libcalls like __atomic_fetch_add_8(). In code like "_Atomic long long a; a++;", clang doesn't emit a libcall. This was causing linker errors on symbols like __sync_fetch_and_add_8. Now that LLVM knows the max atomic size, its AtomicExpandPass changes these 8-byte ops into libcalls. ok mortimer@ 2020-05-30T19:27:11Z drahn drahn@openbsd.org 2020-05-30T19:27:11Z urn:sha1:98c52506dedbd7b4b3f76d15c419a7ea974c7fb5 This should simplify bringup and make it easier to support Big Endian and Little Endian with the same code. May be reconsidered if it causes too many problems with Ports. ok kettenis@ 2020-05-23T07:18:50Z visa visa@openbsd.org 2020-05-23T07:18:50Z urn:sha1:59447aca8d09daa7e01d4745dffe3b139396b8c7 This lets the kernel detect retguard traps and send SIGABRT instead of SIGEMT. SIGEMT does not indicate correctly the nature of the error (stack overflow, violation of control flow). It can confuse the user to restart the program without further investigation. Prompted by and OK deraadt@ OK mortimer@ 2020-04-09T17:08:56Z kettenis kettenis@openbsd.org 2020-04-09T17:08:56Z urn:sha1:00f51392e3b69b727541e329a65fd30b7f432c5e "hard-quad-float" feature is available. Add missing replacement instruction patterns that are needed to emit alternative code for conditional moves of quad-precision floats. ok mortimer@ 2020-04-04T09:54:04Z kettenis kettenis@openbsd.org 2020-04-04T09:54:04Z urn:sha1:3159fc8f233e5ccb749cd05b58cf5b93b8f45263 ok mortimer@ 2019-10-25T00:40:56Z mortimer mortimer@openbsd.org 2019-10-25T00:40:56Z urn:sha1:52446778f86252aa4533d0b08b871472df4e84f6 For this architecture we use separate retguard prologue and epilogue code for static or PIC code. In the PIC case we use some additional code before the retguard epilogue to recover the function start address and the GOT pointer in order to get the per-function random cookie. Much thanks to visa@ for suggestions and advice making it all work. ok deraadt@ visa@ 2019-09-01T16:37:21Z patrick patrick@openbsd.org 2019-09-01T16:37:21Z urn:sha1:d3df0c01b52bb561f932539d0321079fcb70e869 Tested in snaps and package builds Tested on amd64 by naddy@ Tested on arm64 by patrick@ Tested on octeon by visa@ 2019-09-01T16:27:59Z patrick patrick@openbsd.org 2019-09-01T16:27:59Z urn:sha1:b19884b112052f3bf5ff9551374fbd840e2339f2 2019-08-01T01:09:09Z mortimer mortimer@openbsd.org 2019-08-01T01:09:09Z urn:sha1:ac01d30ce880eeb475479bed69a1fa12c43f3cfd LOAD_STACK_GUARD pseudo without consulting the value of useLoadStackGuardNode(), and then tries to add the return from getSDagStackGuard() as a parameter without consulting the return from getIRStackGuard() to see if it should do that. This means that the GlobalISel IRTranslator's implementation for Intrinsic::stackprotector is broken for platforms that implement getIRStackGuard() like we do, and this causes a segfault later when the incomplete LOAD_STACK_GUARD pseudo is lowered in the back end. Since GlobalISel is disabled on aarch64 most of the time anyway, add a bit that disables it for OpenBSD/aarch64 all the time. Fixes a crash when building on aarch64 without retguard, with a stack protector and without optimizations, which manifests when building cross-tools. ok patrick@ deraadt@ 2019-07-28T13:25:25Z visa visa@openbsd.org 2019-07-28T13:25:25Z urn:sha1:63f1d51ba3485ee31405eafae8f0bd217f1ee7b2 - In the N64 mode, properly load the whole immediate value in the destination register even if the lower 32 bits are zero. - Ensure correct alignment of memory operands. - Fix the endianess of memory operands.