| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran
for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done
and manually updated references to renamed files found by that.
llvm-svn: 367452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On Linux we may need preinit_array in static lib and
ubsan_standalone_initializer in shared lib.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38013
llvm-svn: 313851
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: To parser "include" we may need to do binary name substitution.
Reviewers: eugenis, alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D37658
llvm-svn: 312953
|
|
|
|
|
|
|
|
| |
Patch was corrupted by rebase.
This reverts commit r312933
llvm-svn: 312952
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: To parser "include" we may need to do binary name substitution.
Reviewers: eugenis, alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D37658
llvm-svn: 312933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using ASan and UBSan together, the common sanitizer tool name is
set to "AddressSanitizer". That means that when a UBSan diagnostic is
printed out, it looks like this:
SUMMARY: AddressSanitizer: ...
This can confuse users. Fix it so that we always use the correct tool
name when printing out UBSan diagnostics.
Differential Revision: https://reviews.llvm.org/D32066
llvm-svn: 300358
|
|
|
|
|
|
| |
This adds standalone ubsan output to "adb logcat", the same as ASan does.
llvm-svn: 278706
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D10213
llvm-svn: 239020
|
|
|
|
|
|
|
| |
As with the other sanitizers, it is desirable to allow ubsan's output to be
redirected to somewhere other than stderr (and into per-process log files).
llvm-svn: 235277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change
doesn't modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, rsmith, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8646
llvm-svn: 233861
|
|
|
|
| |
llvm-svn: 233295
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SuppressionContext is no longer a singleton, shared by all sanitizers,
but a regular class. Each of ASan, LSan, UBSan and TSan now have their
own SuppressionContext, which only parses suppressions specific to
that sanitizer.
"suppressions" flag is moved away from common flags into tool-specific
flags, so the user now may pass
ASAN_OPTIONS=suppressions=asan_supp.txt LSAN_OPIONS=suppressions=lsan_supp.txt
in a single invocation.
llvm-svn: 230026
|
|
|
|
|
|
|
| |
The new parser is a lot stricter about syntax, reports unrecognized
flags, and will make it easier to implemented some of the planned features.
llvm-svn: 226169
|
|
|
|
|
|
| |
usual in most cases but will not dump coverage on error with -fno-sanitize-recover (that'll be a separate fix)
llvm-svn: 225234
|
|
|
|
| |
llvm-svn: 217652
|
|
|
|
|
|
| |
UBSan is combined with ASan.
llvm-svn: 217616
|
|
|
|
|
|
|
|
|
| |
We may as well just use Symbolizer::GetOrInit() in all the cases.
Don't call Symbolizer::Get() early in tools initialization: these days
it doesn't do any important setup work, and we may as well create the
symbolizer the first time it's actually needed.
llvm-svn: 217558
|
|
|
|
|
|
| |
Based on http://reviews.llvm.org/D4702 by Byoungyoung Lee!
llvm-svn: 214833
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 214258
|
|
|
|
|
|
|
|
| |
We used to initialize symbolizer lazily, but this doesn't work in
various sandboxed environments. Instead, let's be consistent with
the rest of sanitizers.
llvm-svn: 214006
|
|
Specifically, use .preinit_array initialization on Linux and dynamic global
initializer on another platforms. Historically UBSan didn't have any
initialization code and its runtime was stateless. This is no longer the
case - UBSan relies on some non-trivial functionality from sanitizer_common
(e.g. online symbolization) and is now configurable by runtime flags.
Additionally, we've dropped support for enabling UBSan only for a few shared
objects, so UBSan is now always linked into the main executable, so now
we can use similar initialization as all the rest sanitizers.
llvm-svn: 213983
|