summaryrefslogtreecommitdiffstats
path: root/gnu/llvm/lib/Target (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove LLVM 8.0.1 files.patrick2020-08-031783-1010534/+0
|
* Set max atomic size for PowerPC.gkoehler2020-06-041-1/+4
| | | | | | | | | | | | 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@
* Switch Powerpc64 Big Endian to ELFv2 on OpenBSD, as least for now.drahn2020-05-301-0/+2
| | | | | | | | 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@
* Use a distinct trap code with retguard on mips64.visa2020-05-231-2/+3
| | | | | | | | | | | | 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@
* Make sure that we really don't emut quad-precision unless thekettenis2020-04-093-16/+43
| | | | | | | | "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@
* Fix "small pic" secure plt support.kettenis2020-04-043-8/+12
| | | | ok mortimer@
* Add retguard for octeon/mips64.mortimer2019-10-257-1/+437
| | | | | | | | | | 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@
* Merge LLVM 8.0.1 release.patrick2019-09-013-4/+12
| | | | | | | Tested in snaps and package builds Tested on amd64 by naddy@ Tested on arm64 by patrick@ Tested on octeon by visa@
* Import LLVM 8.0.1 release including clang, lld and lldb.patrick2019-09-0125-193/+196
|
* The GlobalISel IRTranslator pass assumes that it is safe to use themortimer2019-08-011-1/+2
| | | | | | | | | | | | | | | | | | 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@
* Address a few issues in the expansion of li.d and li.s:visa2019-07-281-8/+15
| | | | | | | - 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.
* Fix instruction guard. This prevents the compiler from usingvisa2019-07-081-1/+1
| | | | the MIPS64 mul instruction on pre-MIPS64 subtargets.
* Implement the 'h' register constraint on mips64. This lets clang buildvisa2019-07-011-0/+8
| | | | | | | | | | | 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.
* Implement .cplocal directive. Needed when building libcrypto.visa2019-06-243-25/+68
|
* Implement SGE pseudo-instructions. Needed when building libcrypto.visa2019-06-243-0/+99
|
* Fix a bug in memory operand handling. If a load or store uses a symbolvisa2019-06-241-0/+4
| | | | | | | | | | | | as a memory operand, the assembler generates incorrect relocations in PIC mode. As a simple fix, expand the instruction into an address load sequence, which works, that is followed by the actual memory instruction. Note that the generated sequence is not always optimal. If the symbol has a small offset, the offset could be fused with the memory instruction. The fix does not achieve that, however. A symbol offset adds an extra instruction.
* Re-add files that were previously removed but are now part of LLVM 8.0.0.patrick2019-06-231-0/+79
|
* Merge LLVM 8.0.0 release.patrick2019-06-2388-9305/+9392
| | | | | | | | | 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@
* Import LLVM 8.0.0 release including clang, lld and lldb.patrick2019-06-23747-28070/+63065
|
* Re-enable RETGUARD leaf function optimization for arm64.mortimer2019-05-312-2/+2
| | | | | | | | It turns out MachineFrameInfo.hasCalls() is unreliable, because it is up to the backends to update this information whenever they add calls to a function, and this does not always happen. ok kettenis@
* Remove cast that truncates immediate operands to 32 bits. This fixeskettenis2019-04-221-1/+1
| | | | | | genassym.sh on sparc64 when using clang as the compiler. ok claudio@, deraadt@
* Restore previous section after setting the MIPS ABI marker. This keepsvisa2019-04-201-0/+2
| | | | | | | | the .text section in use after the file header, improving compatibility with gcc. Without this change, module-level inline assembly blocks could end up into wrong section. OK kettenis@ guenther@
* retguard-cookie-in-register is slightly unstable on arm64, so surgicallyderaadt2019-04-172-2/+2
| | | | | disable it in upcoming 6.5 release. (phessler and mortimer have the details)
* Emit variable length trap padding in retguard epilogue.mortimer2019-04-021-0/+21
| | | | | | | This adds more trap padding before the return while ensuring that the return is still in the same cache line. ok deraadt@
* Do not store the retguard cookie in frame in leaf functions if possible.mortimer2019-03-314-7/+17
| | | | | | | Makes things slightly faster and also improves security in these functions, since the retguard cookie can't leak via the stack. ok deraadt@
* Improve the X86FixupGadgets pass:mortimer2019-02-223-136/+598
| | | | | | | | | | - Target all four kinds of return bytes (c2, c3, ca, cb) - Fix up instructions using both ModR/M and SIB bytes - Force alignment before instructions with return bytes in immediates - Force alignment before instructions that have return bytes in their encoding - Add a command line switch to toggle the functionality. ok deraadt@
* When generating code for OpenBSD/powerpc, avoid unaligned floating-pointkettenis2019-02-182-0/+9
| | | | | | | | | | | | load and store instructions. The vast majority of PowerPC CPUs that OpenBSD runs on don't implement those and will generate an alignment exceptions. While we do emulate lfd and stfd (to work around GCC bugs), we don't emulate lfs and stfs. It is way more efficient to have the compiler generate code that only uses aligned load and store instructions. Based on a diff from Georg Koehler. ok patrick@, visa@
* Merge LLVM commits r340844, r353818 and r353819 from the 8.0 branchpatrick2019-02-1310-102/+151
| | | | | | | | | | to fix a regression in floating point operations. Bluhm noticed that the bc regression test has been failing after the upgrade to 7.0.1 because setting the floating point control register was in some cases reordered erroneously. Found and tested by bluhm@ ok bluhm@ kettenis@
* Zap unneeded argument to BuildMI().mortimer2019-02-051-1/+1
| | | | ok dlg@
* initialize SaveArgs variable in case neither -msave-args or -mno-save-args are on command-line.semarie2019-02-041-2/+2
| | | | | | and use a bool type for a boolean in C++. ok kettenis@ deraadt@
* implement -msave-args in clang/llvm, like the sun did for gccdlg2019-01-305-15/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Re-add files that were previously removed but are now part of LLVM 7.0.1.patrick2019-01-271-0/+134
|
* Tedu files that got removed in LLVM 7.0.1.patrick2019-01-2717-4226/+0
|
* Merge LLVM 7.0.1 release.patrick2019-01-2722-2031/+3666
| | | | | With fixes from mortimer@ (thanks!) Tested by many, especially naddy@ (thanks!)
* Import LLVM 7.0.1 release including clang, lld and lldb.patrick2019-01-271046-69585/+110140
|
* Use a 64-bit register when required for inline asm on sparc64.kettenis2019-01-171-0/+2
| | | | | | | Without this, values get truncated to 32-bit. Makes a sparc64 kernel actually work when compiled with clang. ok pguenther@, visa@
* Turn on -mretpoline by default in clang on amd64, but turn it offguenther2018-12-302-0/+9
| | | | | | | explicitly in SMALL_KERNEL kernel builds. tweaks from jsg@ and tb@ ok deraadt@ kettenis@
* Enable the integrated assembler on mips64.visa2018-10-211-0/+5
| | | | | | | | Upstream references: https://reviews.llvm.org/D31557 https://reviews.llvm.org/D48515 OK kettenis@
* Add retguard for arm64.mortimer2018-08-126-1/+212
| | | | ok deraadt@
* Refactor retguard to make adding additional arches easier.mortimer2018-08-124-208/+171
|
* Remove unused variable.mortimer2018-06-071-1/+0
| | | | Spotted by Nan Xiao.
* Add RETGUARD to clang for amd64. This security mechanism uses per-functionmortimer2018-06-064-0/+236
| | | | | | | | | | | | | | | | | | | | | | | | | random cookies to protect access to function return instructions, with the effect that the integrity of the return address is protected, and function return instructions are harder to use in ROP gadgets. On function entry the return address is combined with a per-function random cookie and stored in the stack frame. The integrity of this value is verified before function return, and if this check fails, the program aborts. In this way RETGUARD is an improved stack protector, since the cookies are per-function. The verification routine is constructed such that the binary space immediately before each ret instruction is padded with int03 instructions, which makes these return instructions difficult to use in ROP gadgets. In the kernel, this has the effect of removing approximately 50% of total ROP gadgets, and 15% of unique ROP gadgets compared to the 6.3 release kernel. Function epilogues are essentially gadget free, leaving only the polymorphic gadgets that result from jumping into the instruction stream partway through other instructions. Work to remove these gadgets will continue through other mechanisms. Remaining work includes adding this mechanism to assembly routines, which must be done by hand. Many thanks to all those who helped test and provide feedback, especially deaadt, tb, espie and naddy. ok deraadt@
* Add a clang pass that identifies potential ROP gadgets and replaces ROPmortimer2018-04-284-0/+273
| | | | | | | | friendly instructions with safe alternatives. This initial commit fixes 3 instruction forms that will lower to include a c3 (return) byte. Additional problematic instructions can be fixed incrementally using this framework. ok deraadt@
* more undos from the mistake this morningderaadt2018-04-213-56/+287
|
* oops, snapshot tests not ready yetderaadt2018-04-203-293/+56
|
* syncderaadt2018-04-203-0/+6
|
* Tedu files that got removed in LLVM 6.0.0.patrick2018-04-0611-4034/+0
|
* Merge LLVM 6.0.0 release.patrick2018-04-067-451/+698
|
* Import LLVM 6.0.1 release including clang, lld and lldb.patrick2018-04-061065-59671/+134394
| | | | "where is the kaboom?" deraadt@
* Cherry-pick a change from LLVM that marks specific pseudo memorypatrick2017-12-261-4/+2
| | | | | | | | instructions to have side effects so the optimizer does not reorder them across fnstcw/fldcw sequences. Fixes a bug seen in sqlite3 on i386. ok kettenis@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.