WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/gnu/llvm/tools/clang/lib/Basic?h=jd%2Fsimplify-queueing 2020-05-30T19:23:16Z 2020-05-30T19:23:16Z drahn drahn@openbsd.org 2020-05-30T19:23:16Z urn:sha1:949932c898dbe0db8f3e57846975f25e49567f99 ok kettenis@ 2020-05-20T07:07:44Z patrick patrick@openbsd.org 2020-05-20T07:07:44Z urn:sha1:5a51f1c14b8d8ec321a16e1d85f6bed3b9492fa4 Prompted and tested by drahn@ ok deraadt@ drahn@ kettenis@ visa@ 2020-04-05T13:55:53Z kettenis kettenis@openbsd.org 2020-04-05T13:55:53Z urn:sha1:f7d9bb6830ad75deb53c1fcb554dc6445b20a279 other clang platforms do. ok jca@ 2019-09-01T16:27:59Z patrick patrick@openbsd.org 2019-09-01T16:27:59Z urn:sha1:b19884b112052f3bf5ff9551374fbd840e2339f2 2019-07-01T15:15:53Z visa visa@openbsd.org 2019-07-01T15:15:53Z urn:sha1:7c158015691a62568a49a2186cab232e1c7050e1 pieces of software that use the constraint if the compiler claims to be compatible with GCC 4.2.1. Note that the constraint was removed in GCC 4.4. The reason was that 'h' could generate code whose result is unpredictable. The underlying reason is that the HI and LO registers are special, and the optimizer has to be careful when choosing the order of HI/LO accesses. It looks that LLVM has the needed logic. 2019-06-23T22:05:08Z patrick patrick@openbsd.org 2019-06-23T22:05:08Z urn:sha1:f27a781c9811da94fe68b2cf34237c2a61b48c96 Prepared with help from jsg@ and mortimer@ Tested on amd64 by bcallah@, krw@, naddy@ Tested on arm64 by patrick@ Tested on macppc by kettenis@ Tested on octeon by visa@ Tested on sparc64 by claudio@ 2019-06-23T21:36:31Z patrick patrick@openbsd.org 2019-06-23T21:36:31Z urn:sha1:23f101f37937a1bd4a29726cab2f76e0fb038b35 2019-02-10T17:06:03Z kettenis kettenis@openbsd.org 2019-02-10T17:06:03Z urn:sha1:a748f3aef913185ae09270e131d36eed8f9f110d FreeBSD/powerpc. From George Koehler. ok millert@, deraadt@, visa@ 2019-01-30T03:08:12Z dlg dlg@openbsd.org 2019-01-30T03:08:12Z urn:sha1:728e23dfc36a7a5f9a19f349b6c8d489de3d3859 this is a bit different to gcc as gcc likes to use movs to move stuff on and off the stack, and directly updates the stack pointers with add and sub instructions. llvm prefers to use push and pop instructions, is a lot more careful about keeping track of how much stuff is currently on the stack, and generally pops the frame pointer rather than do maths on it. -msave-args adds a bunch of pushes as the first thing a function prologue does. to keep the stack aligned, if there's an odd number of arguments to the function it pushes the first one again to put the frame back on a 16 byte boundary. to undo the pushes the frame pointer needs to be updated in function epilogues. clang emits a series of pops to fix up the registers on the way out, but popping saved arguments is a waste of time and harmful to actual data in the function. rather than add an offset to the stack pointer, -msave-args emits a leaveq operation to fix up the frame again. leaveq is effectively mov rbp,rsp; pop rbp, and is a single byte, meaning there's less potential for gadgets compared to a direct add to rsp, or an explicit mov rbp,rsp. the only thing missing compared to the gcc implementation is adding the SUN_amd64_parmdump dwarf flag to affected functions. if someone can tell me how to add that from the frame lowering code, let me know. when enabled in kernel builds again, this will provide useful arguments in ddb stack traces again. 2019-01-27T17:11:29Z patrick patrick@openbsd.org 2019-01-27T17:11:29Z urn:sha1:9f520fd6abbfde117cf551fb4eacdd2687a606a9