summaryrefslogtreecommitdiffstats
path: root/gnu/llvm/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* syncderaadt2018-04-203-0/+6
|
* Tedu files that got removed in LLVM 6.0.0.patrick2018-04-06217-20276/+0
|
* Merge LLVM 6.0.0 release.patrick2018-04-0613-1270/+1414
|
* Import LLVM 6.0.1 release including clang, lld and lldb.patrick2018-04-061863-89808/+202611
| | | | "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@
* Merge LLVM 5.0.1 release.patrick2017-12-241-5/+14
|
* Import LLVM 5.0.1 release including clang, lld and lldb.patrick2017-12-2454-172/+852
|
* The compiler is generally free to allocate general purpose registers in whatevermortimer2017-11-211-3/+3
| | | | | | | | | | | | | | | | | | | | | order it chooses. Reasons for choosing one register before another usually incl ude compiled instruction size (avoidance of REX prefixes, etc.) or usage convent ions, but somehow haven't included security implications in the compiled bytecod e. Some bytecode is more useful in polymorphic ROP sequences than others, so it seems prudent to try to avoid that bytecode when possible. This patch moves EBX/RBX towards the end of the allocation preference for 32 and 64 bit general purpose registers. Some instructions using RBX/EBX/BX/BL as a de stination register end up with a ModR/M byte of C3 or CB, which is often useful in ROP gadgets. Because these gadgets often occur in the middle of functions, th ey exhibit somewhat higher diversity than some other C3/CB terminated gadgets. T his change removes about 3% of total gadgets from the kernel, but about 6% of un ique gadgets. There are other possible changes in this direction. BX/BL are obvious next targe ts for avoidance, and MM3/XMM3 may also be useful to try to avoid if possible. ok deraadt@
* Tedu files that got removed in LLVM 5.0.0.patrick2017-10-0427-3433/+0
|
* Tedu files that got removed in LLVM 5.0.0.patrick2017-10-0441-25733/+0
|
* Merge LLVM 5.0.0 release.patrick2017-10-0412-970/+2107
|
* Import LLVM 5.0.0 release including clang, lld and lldb.patrick2017-10-042058-83626/+261017
|
* make clang include a FILE symbol for .(s|S) filesrobert2017-09-281-1/+6
| | | | | | | | | | | | | This is mostly needed by syspatch at the moment to be to be able to re-link in the same order as the original libraries were linked with by relying on the readelf(1) and without this .(s|S) assembly files were not getting a file directive. A bug reports has been filed as well: https://bugs.llvm.org/show_bug.cgi?id=34019 ok deraadt@
* Use int3 trap padding between functions instead of trapsleds with a leading jump.mortimer2017-08-013-1/+36
| | | | ok deraadt@
* Fix trapsleds on i386mortimer2017-07-291-9/+0
| | | | ok deraadt@
* if we return nullptr for a "noexec" section, then don't change section.espie2017-06-281-2/+5
| | | | | | prevents core dumps :) okay tedu@
* trapsleds for clang, similar to the change on gas side.deraadt2017-06-271-31/+15
| | | | | Also from Todd Mortimer tested by espie
* For a decade or more, we've patched gcc to make -fno-ident the default.tedu2017-06-211-1/+1
| | | | | | clang doesn't seem to have a command line option for the feature, so just hard wire it off. We don't need advertisements in our binaries. ok deraadt
* openbsd does not use nonexec stack segment header hints.tedu2017-05-291-1/+1
| | | | | | | in fact, false is a much better default for UsesNonexecutableStackSection. platforms that require it can reenable, instead, saving the rest of us an unnecessary program header (causes trouble for some special binaries). ok kettenis
* Merge LLVM 4.0.0 release.patrick2017-03-142-5/+7
|
* Import LLVM 4.0.0 release including clang and lld.patrick2017-03-1490-1199/+1538
|
* Disable loop idiom recognition for _libc_memset and _libc_memcpy. These arekettenis2017-02-251-0/+2
| | | | | | | | | | | | the internal names we use in libc for memset and memcpy and having the compiler optimize them as calls to memset and memcpy will lead to infinite recursion. This is a temporary solution while guenther@ tries to figure out a better way to force calls from inside libc via identifiers that are of hidden visibility. ok jsg@, patrick@
* Merge LLVM 4.0.0 rc1patrick2017-01-2453-6160/+872
|
* Import LLVM 4.0.0 rc1 including clang and lld to help the currentpatrick2017-01-241811-80829/+193312
| | | | 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@
* Disable the Load Stack Guard for OpenBSD on AArch64. We don't use itpatrick2017-01-142-1/+2
| | | | | | | | on any other platform and it causes a segfault in combination with our IR Stack Guard. "looks reasonable" kettenis@ "looks good to me" stefan@
* Merge LLVM 3.9.1patrick2017-01-14185-18781/+92
|
* Import LLVM 3.9.1 including clang and lld.patrick2017-01-141839-90633/+214211
|
* 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-032430-0/+1214328
ok hackroom@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.