| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This reverts commit 94d4ca90040a5f55ee29f48043881437de56681e.
I reverted 68a235d07f9e70 again in
916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e.
(cherry picked from commit 93c73d4834a96ac749dabb624e07f9a146186875)
|
|
|
|
|
|
| |
This reverts commit 70342641b3c064b1cdf90d16902b937e7a21ecf2.
68a235d relanded in abb00753069, so this relands the gn port of it.
|
|
|
|
|
| |
This reverts commit 6ff6d32ebfec3150aa462cd31042b5719edb84da,
because 68a235d07f9e70 was reverted in e406cca5f9.
|
| |
|
|
|
|
|
|
|
| |
These tests are deliberately mismatching new and delete, so the warnings
are just noise.
Differential Revision: https://reviews.llvm.org/D71783
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D71104
|
|
|
|
|
|
|
|
| |
Scudo only supports building for android/linux/fuchsia, so require target_os to
be one of linux/fuchsia to do a stage2_unix scudo build. Android is already
covered by the stage2_android* toolchains below.
Differential Revision: https://reviews.llvm.org/D71131
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D71081
|
| |
|
|
|
|
|
| |
This reverts commit 88276ddbfea753ac13da5a64c2020b7b0a06617f.
The original change relanded.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This header fragment is useful on its own for any consumer that wants
to use custom instruction profile runtime with the LLVM instrumentation.
The concrete use case is in Fuchsia's kernel where we want to use
instruction profile instrumentation, but we cannot use the compiler-rt
runtime because it's not designed for use in the kernel environment.
This change allows installing this header as part of compiler-rt.
Differential Revision: https://reviews.llvm.org/D64532
|
|
|
|
|
| |
This reverts commit e4ec2ecf6d4768d681a89263c0a4d29a7b7761ad.
1689ad27af was reverted as well.
|
| |
|
|
|
|
|
|
| |
for Android aarch64 and arm.
Differential Revision: https://reviews.llvm.org/D69681
|
|
|
|
|
|
| |
Fixes stage2 cross compilation.
Differential Revision: https://reviews.llvm.org/D69680
|
| |
|
|
|
|
| |
llvm-svn: 371858
|
|
|
|
| |
llvm-svn: 371848
|
|
|
|
| |
llvm-svn: 371102
|
|
|
|
| |
llvm-svn: 371091
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One problem with untagging memory in landing pads is that it only works
correctly if the function that catches the exception is instrumented.
If the function is uninstrumented, we have no opportunity to untag the
memory.
To address this, replace landing pad instrumentation with personality function
wrapping. Each function with an instrumented stack has its personality function
replaced with a wrapper provided by the runtime. Functions that did not have
a personality function to begin with also get wrappers if they may be unwound
past. As the unwinder calls personality functions during stack unwinding,
the original personality function is called and the function's stack frame is
untagged by the wrapper if the personality function instructs the unwinder
to keep unwinding. If unwinding stops at a landing pad, the function is
still responsible for untagging its stack frame if it resumes unwinding.
The old landing pad mechanism is preserved for compatibility with old runtimes.
Differential Revision: https://reviews.llvm.org/D66377
llvm-svn: 369721
|
|
|
|
| |
llvm-svn: 368333
|
|
|
|
| |
llvm-svn: 368097
|
|
|
|
| |
llvm-svn: 367970
|
|
|
|
| |
llvm-svn: 367464
|
|
|
|
|
|
|
|
| |
See https://reviews.llvm.org/D58620 for discussion.
Note how the comment in the file already said ".cpp" :)
llvm-svn: 367460
|
|
|
|
| |
llvm-svn: 367457
|
|
|
|
| |
llvm-svn: 367454
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D65518
llvm-svn: 367450
|
|
|
|
|
|
|
|
| |
For now, it only builds the x86_64 slice.
Differential Revision: https://reviews.llvm.org/D65513
llvm-svn: 367449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compiler-rt's builtin library has generic implementations of many
functions, and then per-arch optimized implementations of some.
In the CMake build, both filter_builtin_sources() and an explicit loop
at the end of the build file (see D37166) filter out the generic
versions if a per-arch file is present.
The GN build wasn't doing this filtering. Just do the filtering manually
and explicitly, instead of being clever.
While here, also remove files from the mingw/arm build that are
redundantly listed after D39938 / r318139 (both from the CMake and the
GN build).
While here, also fix a target_os -> target_cpu typo.
Differential Revision: https://reviews.llvm.org/D65512
llvm-svn: 367448
|
|
|
|
| |
llvm-svn: 366763
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These lit configuration files are really Python source code. Using the
.py file extension helps editors and tools use the correct language
mode. LLVM and Clang already use this convention for lit configuration,
this change simply applies it to all of compiler-rt.
Reviewers: vitalybuka, dberris
Differential Revision: https://reviews.llvm.org/D63658
llvm-svn: 364591
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I executed gn.py gen out/gn I got the following error:
ERROR at //compiler-rt/lib/builtins/BUILD.gn:162:7: Only source, header, and object files belong in the sources of a static_library. //compiler-rt/lib/builtins/emutls.c is not one of the valid types.
"emutls.c ",
^----------
See //compiler-rt/lib/BUILD.gn:3:5: which caused the file to be included.
"//compiler-rt/lib/builtins",
^---------------------------
It turns out to be that the latest gn doesn't accept ill-format file name. And the emutls.c above has a trailing space.
Remove the trailing space should work.
Patch By: myhsu
Differential Revision: https://reviews.llvm.org/D63449
llvm-svn: 364162
|
|
|
|
| |
llvm-svn: 363610
|
|
|
|
| |
llvm-svn: 363609
|
|
|
|
| |
llvm-svn: 360629
|
|
|
|
| |
llvm-svn: 360553
|
|
|
|
|
|
| |
format`
llvm-svn: 357906
|
|
|
|
|
|
|
|
|
|
| |
This change also introduces the clang_enable_per_target_runtime_dir
to enable the use of per-target runtime directory layout which is the
equivalent of LLVM_ENABLE_PER_TARGET_RUNTIME_DIR CMake option.
Differential Revision: https://reviews.llvm.org/D60332
llvm-svn: 357850
|
|
|
|
| |
llvm-svn: 357830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is support for building compiler-rt builtins, The library build
should be complete for a subset of supported platforms, but not all
CMake options have been replicated in GN.
We always use the just built compiler to build all the runtimes, which
is equivalent to the CMake runtimes build. This simplifies the build
configuration because we don't need to support arbitrary host compiler
and can always assume the latest Clang. With GN's toolchain support,
this is significantly more efficient than the CMake runtimes build.
Differential Revision: https://reviews.llvm.org/D60331
llvm-svn: 357821
|
|
|
|
|
|
|
|
|
|
|
| |
It hasn't seen active development in years, and it hasn't reached a
state where it was useful.
Remove the code until someone is interested in working on it again.
Differential Revision: https://reviews.llvm.org/D59133
llvm-svn: 355862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance.
In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable.
The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format:
Registers where the failure occurred (pc 0x0055555561b4):
x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025
x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001
x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000
x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000
x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078
x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000
x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000
x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4
... and prints after the dump of memory tags around the buggy address.
Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging.
Reviewers: pcc, eugenis
Reviewed By: pcc, eugenis
Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58857
llvm-svn: 355738
|
|
|
|
|
|
|
|
| |
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D59037
llvm-svn: 355617
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D58839
llvm-svn: 355467
|
|
|
|
|
|
|
|
| |
This build target is currently unused, but after r355144 the sync script
started complaining about cfi.cpp not being listed, and this makes the
script happy again.
llvm-svn: 355275
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Intercept vfork on arm, aarch64, i386 and x86_64.
Reviewers: pcc, vitalybuka
Subscribers: kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D58533
llvm-svn: 355030
|