| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gadgets
Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph.
More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK).
Also adds a new target feature to X86: +lvi-load-hardening
The feature can be added via the clang CLI using -mlvi-hardening.
Differential Revision: https://reviews.llvm.org/D75936
|
|
|
|
|
|
|
|
|
| |
Injection (LVI) Gadgets"
This reverts commit c74dd640fd740c6928f66a39c7c15a014af3f66f.
Reverting to address coding standard issues raised in post-commit
review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gadgets
Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph.
More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK).
Also adds a new target feature to X86: +lvi-load-hardening
The feature can be added via the clang CLI using -mlvi-hardening.
Differential Revision: https://reviews.llvm.org/D75936
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass replaces each indirect call/jump with a direct call to a thunk that looks like:
lfence
jmpq *%r11
This ensures that if the value in register %r11 was loaded from memory, then
the value in %r11 is (architecturally) correct prior to the jump.
Also adds a new target feature to X86: +lvi-cfi
("cfi" meaning control-flow integrity)
The feature can be added via clang CLI using -mlvi-cfi.
This is an alternate implementation to https://reviews.llvm.org/D75934 That merges the thunk insertion functionality with the existing X86 retpoline code.
Differential Revision: https://reviews.llvm.org/D76812
|
|
|
|
|
|
|
| |
D80647 did not fix https://bugs.llvm.org/show_bug.cgi?id=46076
This is the fix.
(cherry picked from commit b9c6871a9570975827dc0bbeb39131c99c8daf8e)
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://bugs.llvm.org/show_bug.cgi?id=46076
Reviewed By: nickdesaulniers, pcc
Differential Revision: https://reviews.llvm.org/D80647
(cherry picked from commit a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When forking in several threads, the counters were written out in using the same global static variables (see GCDAProfiling.c): that leads to crashes.
So when there is a fork, the counters are resetted in the child process and they will be dumped at exit using the interprocess file locking.
When there is an exec, the counters are written out and in case of failures they're resetted.
Reviewers: jfb, vsk, marco-c, serge-sans-paille
Reviewed By: marco-c, serge-sans-paille
Subscribers: llvm-commits, serge-sans-paille, dmajor, cfe-commits, hiraditya, dexonsmith, #sanitizers, marco-c, sylvestre.ledru
Tags: #sanitizers, #clang, #llvm
Differential Revision: https://reviews.llvm.org/D78477
(cherry picked from commit bec223a9bc4eb9747993ee9a4c1aa135c32123e6)
|
|
|
|
|
|
|
|
|
|
| |
A two-stage ThinLTO build previously failed the clang/test/Driver/hurd.c test because of a static_cast in "tools::gnutools::Linker::ConstructJob()" which wrongly converted an instance of "clang::driver::toolchains::Hurd" into that of "clang::driver::toolchains::Linux". ThinLTO would later devirtualize the "ToolChain.getDynamicLinker(Args)" call and use "Linux::getDynamicLinker()" instead, causing the test to generate a wrong "-dynamic-linker" linker flag (/lib/ld-linux.so.2 instead of /lib/ld.so)
Fixes PR45061.
Differential Revision: https://reviews.llvm.org/D75373
(cherry picked from commit 7e77cf473ac9d8f8b65db017d660892f1c8f4b75)
|
|
|
|
|
|
|
|
|
| |
This fixes an issue with clang issuing a warning about unknown CUDA SDK if it's
detected during non-CUDA compilation.
Differential Revision: https://reviews.llvm.org/D76030
(cherry picked from commit eb2ba2ea953b5ea73cdbb598f77470bde1c6a011)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in llvmorg-10-init-12188-g25ce33a6e4f is a breaking change for
users of older linkers who don't pass a version parameter, which
prevents a drop-in clang upgrade. Old tools can't know about what future
tools will do, so as a general principle the burden should be new tools
to be compatible by default. Also, for comparison, none of the other
tests of Version within AddLinkArgs add any new behaviors unless the
version is explicitly specified. Therefore, this patch changes the
-platform_version behavior from opt-out to opt-in.
Patch by David Major!
Differential revision: https://reviews.llvm.org/D74784
(cherry picked from commit 5122e828701c88f8d53ee881bc68f3904454d154)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes PR44896. For IR input files, option fdiscard-value-names
should be ignored as we need named values in loadModule().
Commit 60d3947922 sets this option after loadModule() where valued names
already created. This creates an inconsistent state in setNameImpl()
that leads to a seg fault.
This patch forces fdiscard-value-names to be false for IR input files.
This patch also emits a warning of "ignoring -fdiscard-value-names" if
option fdiscard-value-names is explictly enabled in the commandline for
IR input files.
Differential Revision: https://reviews.llvm.org/D74878
(cherry picked from commit 11857d49948b845dcfd7c7f78595095e3add012d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After b18cb9c47, clang would sometimes prefer the host C++ includes
(e.g. in /usr/include/c++/v1) before those specified via --sysroot.
While this behavior may be desirable on Linux, it is not so on FreeBSD,
where we make extensive use of --sysroot during the build of the base
system. In that case, clang must *not* search outside the sysroot,
except for its own internal headers.
Add an override addLibCxxIncludePaths() to restore the old behavior,
which is to simply append /usr/include/c++/v1 to the specified sysroot.
While here, apply clang-format to the FreeBSD specific toolchain files.
Fixes PR44923.
(cherry picked from commit 62654cab7e654384ba503d6b62b1054cde19a553)
|
|
|
|
|
|
|
|
|
|
| |
As discussed in https://reviews.llvm.org/D74447, this patch disables integrated-cc1 behavior if there's more than one job to be executed. This is meant to limit memory bloating, given that currently jobs don't clean up after execution (-disable-free is always active in cc1 mode).
I see this behavior as temporary until release 10.0 ships (to ease merging of this patch), then we'll reevaluate the situation, see if D74447 makes more sense on the long term.
Differential Revision: https://reviews.llvm.org/D74490
(cherry picked from commit 20f1abe306d030e99f56185a3aa077ffadf59b8a)
|
|
|
|
|
|
|
|
|
|
|
| |
crashing when generating crash diagnostics when '#pragma clang __debug ..."
This re-lands commits f41ec709d9d388dc43469e6ac7f51b6313f7e4af (https://reviews.llvm.org/D74076)
and commit 5fedc2b410853a6aef05e8edf19ebfc4e071e28f (https://reviews.llvm.org/D74070)
The previous build break was caused by '#pragma clang __debug llvm_unreachable' used in a non-assert build. Move it to a separate test in crash-report-with-asserts.c.
(cherry picked from commit 75f09b54429bee17a96e2ba7a2ac0f0a8a7f7e74)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes clang somewhat forward-compatible with new CUDA releases
without having to patch it for every minor release without adding
any new function.
If an unknown version is found, clang issues a warning (can be disabled
with -Wno-cuda-unknown-version) and assumes that it has detected
the latest known version. CUDA releases are usually supersets
of older ones feature-wise, so it should be sufficient to keep
released clang versions working with minor CUDA updates without
having to upgrade clang, too.
Differential Revision: https://reviews.llvm.org/D73231
(cherry picked from commit 12fefeef203ab4ef52d19bcdbd4180608a4deae1)
|
|
|
|
|
|
|
|
|
|
| |
__attribute__((patchable_function_entry(N,M))) where M>0
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D73072
(cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue was reported by @xazax.hun here: https://reviews.llvm.org/D69825#1827826
"This patch (D69825) breaks scan-build-py which parses the output of "-###" to get -cc1 command. There might be other tools with the same problems. Could we either remove (in-process) from CC1Command::Print or add a line break?
Having the last line as a valid invocation is valuable and there might be tools relying on that."
Differential Revision: https://reviews.llvm.org/D72982
(cherry picked from commit 133a7e631cee97965e310f0d110739217427fd3d)
|
|
|
|
|
|
|
|
|
|
|
| |
This change replaces the manual building of executable paths
using llvm::sys::path::append with GetProgramPath.
This enables adding other paths in case executables reside
in different directories and makes the code easier to read.
Differential Revision: https://reviews.llvm.org/D72903
(cherry picked from commit 24d7a0935bea390fc444f6ac8cf02447fe8d6917)
|
|
|
|
|
|
|
| |
This reverts commit 23058f9dd4d7e18239fd63b6da52549514b45fda. It breaks
builds of cuda code somehow in some cases.
(cherry picked from commit 6b29aa21180cf14bfb619d38fc4826913cabfb66)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flags are clang's default UI is flags.
We can have an env var in addition to that, but in D69825 nobody has yet
mentioned why this needs an env var, so omit it for now. If someone
needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS
mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1
for example).
Also mention the cc1-in-process change in the release notes.
Also spruce up the test a bit so it actually tests something :)
Differential Revision: https://reviews.llvm.org/D72769
(cherry picked from commit 8e5018e990b701391e6c33ba85b012343df67272)
|
|
|
|
| |
This reverts commit 57cf6ee9c84434161088c39a6f8dd2aae14eb12d.
|
|
|
|
|
|
|
|
| |
These driver options perform some checking and delegate to MC options -x86-align-branch* and -x86-branches-within-32B-boundaries.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D72463
|
|
|
|
| |
NVPTX does not support RTTI, so disable it by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This adds the __riscv_bitmanip macro and the 'b' target feature to enable it.
Reviewers: asb, simoncook, lewis-revill, PaoloS, lenary
Reviewed By: lenary
Subscribers: Jim, rbar, johnrusso, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71553
|
| |
|
|
|
|
|
|
|
|
|
| |
The option will limit debug info by only emitting complete class
type information when its constructor is emitted.
This patch changes comparisons with LimitedDebugInfo to use the new
level instead.
Differential Revision: https://reviews.llvm.org/D72427
|
|
|
|
|
|
| |
This should be the default on Fuchsia.
Differential Revision: https://reviews.llvm.org/D70576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for the cc1 invocation
With this patch, the clang tool will now call the -cc1 invocation directly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process.
This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can be costly (Windows) and/or impacted by a antivirus.
It also makes debugging a bit easier, as there's no need to attach to the secondary -cc1 process anymore, breakpoints will be hit inside the same process.
Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means.
This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the previous behavior, where any -cc1 invocation will create/fork a secondary process.
At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment variable. Setting it and will override the compile-time setting. A value of 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before.
Differential Revision: https://reviews.llvm.org/D69825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which is the default TLS model for non-PIC objects. This allows large/
many thread local variables or a compact/fast code in an executable.
Specification is same as that of GCC. For example, the code model
option precedes the TLS size option.
TLS access models other than local-exec are not changed. It means
supoort of the large code model is only in the local exec TLS model.
Patch By KAWASHIMA Takahiro (kawashima-fj <t-kawashima@fujitsu.com>)
Reviewers: dmgreen, mstorsjo, t.p.northover, peter.smith, ostannard
Reviewd By: peter.smith
Committed by: peter.smith
Differential Revision: https://reviews.llvm.org/D71688
|
|
|
|
|
|
|
| |
All 130+ f_Group flags that take an argument allow it after a '=',
except for fdebug-complation-dir. Add a Joined<> alias so that
it behaves consistently with all the other f_Group flags.
(Keep the old Separate flag for backwards compat.)
|
|
|
|
|
|
|
|
|
| |
Follow-up of D72014. It is more appropriate to use a target
feature instead of a SubTypeArch to express the difference.
Reviewed By: #powerpc, jhibbits
Differential Revision: https://reviews.llvm.org/D72433
|
|
|
|
|
|
|
|
|
|
|
| |
In the backend, this feature is implemented with the function attribute
"patchable-function-entry". Both the attribute and XRay use
TargetOpcode::PATCHABLE_FUNCTION_ENTER, so the two features are
incompatible.
Reviewed By: ostannard, MaskRay
Differential Revision: https://reviews.llvm.org/D72222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Architecturally, it's allowed to have MVE-I without an FPU, thus
-mfpu=none should not disable MVE-I, or moves to/from FP-registers.
This patch removes `+/-fpregs` from features unconditionally added to
target feature list, depending on FPU and moves the logic to Clang
driver, where the negative form (`-fpregs`) is conditionally added to
the target features list for the cases of `-mfloat-abi=soft`, or
`-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative
form is added by the driver, the positive one is derived from other
features in the backend.
Differential Revision: https://reviews.llvm.org/D71843
|
|
|
|
|
|
|
|
| |
Apple's CPUs are called A7-A13 in official communication, occasionally with
weird suffixes which we probably don't need to care about. This adds each one
and describes its features. It also switches the default CPU to the canonical
name for Cyclone, but leaves legacy support in so that existing bitcode still
compiles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to D53384, the default was switched from -fno-PIC to -fPIC to
work around a -fsanitize=leak bug on big-endian.
This gratuitous difference between little-endian and big-endian is
undesired, and not acceptable on powerpc64-unknown-freebsd. If
-fsanitize=leak still has the problem, we should consider defaulting to
-fPIC/-fPIE only when -fsanitize=leak is specified (see SanitizerArgs::requiresPIE())
powerpc64-ibm-aix is unaffected: it still defaults to -fPIC.
powerpc64-linux-musl is unaffected (-fPIE since D39588): it still defaults to -fPIE.
Reviewed By: #powerpc, jhibbits
Differential Revision: https://reviews.llvm.org/D72363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Every powerpc64le platform uses elfv2.
For powerpc64, the environments "elfv1" and "elfv2" were added for
FreeBSD ELFv1->ELFv2 migration in D61950. FreeBSD developers have
decided to use OS versions to select ABI, and no one is relying on the
environments.
Also use elfv2 on powerpc64-linux-musl.
Users can always use -mabi=elfv1 and -mabi=elfv2 to override the default
ABI.
Reviewed By: adalava
Differential Revision: https://reviews.llvm.org/D72352
|
|
|
|
|
|
| |
Add this option to change the default launch bounds.
Differential Revision: https://reviews.llvm.org/D71221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is a clean up for https://reviews.llvm.org/D72247.
Reviewers: MaskRay, craig.topper, jhenderson
Reviewed By: MaskRay
Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D72320
|
|
|
|
|
|
| |
Reviewed By: craig.topper, skan
Differential Revision: https://reviews.llvm.org/D72247
|
|
|
|
| |
As per the Developer Policy, upon obtaining commit access.
|
|
|
|
| |
As per the Developer Policy, upon obtaining commit access.
|
|
|
|
|
|
|
|
|
|
|
| |
Linux' current addLibCxxIncludePaths and addLibStdCxxIncludePaths
are actually almost non-Linux-specific at all, and can be reused
almost as such for all gcc toolchains. Only keep
Android/Freescale/Cray hacks in Linux's version.
Patch by sthibaul (Samuel Thibault)
Differential Revision: https://reviews.llvm.org/D69758
|
|
|
|
|
|
|
| |
-mpacked-stack is currently not supported with -mbackchain, so this should
result in a compilation error message instead of being silently ignored.
Review: Ulrich Weigand
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D71802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc/config/{i386,s390} support -mnop-mcount. We currently only support
-mnop-mcount for SystemZ. The function attribute "mnop-mcount" is
ignored on other targets.
gcc/config/{i386,s390} support -mfentry. We currently only support
-mfentry for X86 and SystemZ. TargetOpcode::FENTRY_CALL is not handled
on other targets.
% clang -target aarch64 -pg -mfentry a.c -c
fatal error: error in backend: Not supported instr: <MCInst 21>
-mfentry, -mrecord-mcount, and -mnop-mcount were invented for Linux
ftrace. Linux uses $(call cc-option-yn,-mrecord-mcount) to detect if the
specific feature is available. Reject unsupported features so that Linux
build system will not wrongly consider them available and cause
build/runtime failures.
Note, GCC has stricter checks that we do not implement, e.g. -fpic/-fpie
-fnop-mcount is not allowed on x86, -fpic/-fpie -mfentry is not allowed
on x86-32.
|
|
|
|
|
|
|
|
|
|
|
| |
GCC's x86 and s390 ports support -mrecord-mcount. Other ports reject the
option.
aarch64-linux-gnu-gcc: error: unrecognized command line option ‘-mrecord-mcount’
Allowing this option can cause failures when building Linux kernel for
aarch64, powerpc64, etc, which will think the feature is available if
the clang command returns 0.
|
|
|
|
|
|
|
| |
The checker can diagnose handle use after releases, double releases, and
handle leaks.
Differential Revision: https://reviews.llvm.org/D70470
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D70919
|
|
|
|
|
|
|
| |
Method '-[NSCoder decodeValueOfObjCType:at:]' is not only deprecated
but also a security hazard, hence a loud check.
Differential Revision: https://reviews.llvm.org/D71728
|
|
|
|
|
|
|
|
|
|
| |
Recognize -mrecord-mcount from the command line and add a function attribute
"mrecord-mcount" when passed.
Only valid on SystemZ (when used with -mfentry).
Review: Ulrich Weigand
https://reviews.llvm.org/D71627
|