summaryrefslogtreecommitdiffstats
path: root/gnu/llvm/lib/CodeGen (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove LLVM 8.0.1 files.patrick2020-08-03292-235676/+0
|
* Don't make an illegal adde. Avoids fatal error on PowerPC.gkoehler2020-05-021-1/+3
| | | | | | | | | | | | When the DAG truncates an ISD::ADDE node, DAGCombiner may optimize it by making an adde with smaller operands. PowerPC has i1 registers, and may truncate an i32 adde to i1, but an i1 adde is not legal for PowerPC, and the legalize-ops phase can't fix it. This was causing "fatal error: error in backend: Cannot select..." cwen@ reported the error ok mortimer@ kettenis@ deraadt@
* Move the hashed __retguard_* symbols into individual sections and markguenther2019-11-091-3/+5
| | | | | | | | | | | them as COMDATs so that the linker can individually discard them, instead of just ignoring duplicate symbols but keep the (duplicate) space. On amd64, this reduces the size of the kernel OPENBSD_RANDOM segment by 82% and the libc OPENBSD_RANDOM segment by 15%. A port that tb@ is working on experienced a 97.3% reduction...which let it actually run. ok mortimer@ deraadt@
* Import LLVM 8.0.1 release including clang, lld and lldb.patrick2019-09-011-0/+6
|
* Ensure stack protector slot access is resolved by PEI.mortimer2019-08-121-0/+4
| | | | | | | | On arm64, arm, and ppc it is possible that a large stack frame will cause the stack protector slot to be reallocated at the wrong end of the frame. Noticed by tj@. ok patrick@.
* Merge LLVM 8.0.0 release.patrick2019-06-2312-717/+283
| | | | | | | | | 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-23163-7710/+16820
|
* Re-enable RETGUARD leaf function optimization for arm64.mortimer2019-05-311-1/+14
| | | | | | | | 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@
* Do not store the retguard cookie in frame in leaf functions if possible.mortimer2019-03-311-6/+45
| | | | | | | Makes things slightly faster and also improves security in these functions, since the retguard cookie can't leak via the stack. ok deraadt@
* Tedu files that got removed in LLVM 7.0.1.patrick2019-01-273-1309/+0
|
* Merge LLVM 7.0.1 release.patrick2019-01-276-267/+490
| | | | | With fixes from mortimer@ (thanks!) Tested by many, especially naddy@ (thanks!)
* Import LLVM 7.0.1 release including clang, lld and lldb.patrick2019-01-27231-9827/+20858
|
* Refactor retguard to make adding additional arches easier.mortimer2018-08-122-20/+189
|
* Emit trap alignment between basic blocks that are unrechable viamortimer2018-06-221-3/+7
| | | | | | | fallthrough. Avoids unnecessary jmp instructions in the middle of functions and makes disassembly nicer to read. ok guenther@ mlarkin@ deraadt@
* Put the new retguard symbols in their own section,guenther2018-06-121-1/+1
| | | | | | | '.openbsd.randomdata.retguard', to make them easier to work with in the kernel hibernate code. ok mortimer@ deraadt@
* Add RETGUARD to clang for amd64. This security mechanism uses per-functionmortimer2018-06-064-2/+102
| | | | | | | | | | | | | | | | | | | | | | | | | 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@
* Tedu files that got removed in LLVM 6.0.0.patrick2018-04-064-2500/+0
|
* Merge LLVM 6.0.0 release.patrick2018-04-063-633/+319
|
* Import LLVM 6.0.1 release including clang, lld and lldb.patrick2018-04-06236-10015/+18534
| | | | "where is the kaboom?" deraadt@
* Import LLVM 5.0.1 release including clang, lld and lldb.patrick2017-12-246-15/+47
|
* Tedu files that got removed in LLVM 5.0.0.patrick2017-10-041-33/+0
|
* Merge LLVM 5.0.0 release.patrick2017-10-043-170/+443
|
* Import LLVM 5.0.0 release including clang, lld and lldb.patrick2017-10-04220-10831/+23899
|
* Use int3 trap padding between functions instead of trapsleds with a leading jump.mortimer2017-08-011-1/+28
| | | | ok deraadt@
* Import LLVM 4.0.0 release including clang and lld.patrick2017-03-1415-142/+213
|
* Merge LLVM 4.0.0 rc1patrick2017-01-243-81/+275
|
* Import LLVM 4.0.0 rc1 including clang and lld to help the currentpatrick2017-01-24200-7570/+19563
| | | | development effort on OpenBSD/arm64.
* Restore setting the visibility of __guard_local to hidden for betterguenther2017-01-201-1/+4
| | | | | | | code generation. Use dyn_case_or_null instead of a static cast to solve the crashes in the previous code. ok stefan@ kettenis@
* Merge LLVM 3.9.1patrick2017-01-1416-1807/+92
|
* Import LLVM 3.9.1 including clang and lld.patrick2017-01-14199-11664/+26288
|
* Backport https://reviews.llvm.org/rL279449 from upstreamstefan2016-09-071-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | ok pascal@ Original commit message: [SSP] Do not set __guard_local to hidden for OpenBSD SSP guard_local is defined as long on OpenBSD. If the source file contains a definition of guard_local, it mismatches with the int8 pointer type used in LLVM. In that case, Module::getOrInsertGlobal() returns a cast operation instead of a GlobalVariable. Trying to set the visibility on the cast operation leads to random segfaults (seen when compiling the OpenBSD kernel, which also runs with stack protection). In the kernel, the hidden attribute does not matter. For userspace code, guard_local is defined as hidden in the startup code. If a program re-defines guard_local, the definition from the startup code will either win or the linker complains about multiple definitions (depending on whether the re-defined __guard_local is placed in the common segment or not). It also matches what gcc on OpenBSD does.
* Use the space freed up by sparc and zaurus to import LLVM.pascal2016-09-03232-0/+172476
ok hackroom@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.