| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
The original attempt, r319525 was reverted in r319526 due
to the failures in compiler-rt standalone builds.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319575 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit r319525.
This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio
llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
if root.host_os not in ['Linux'] or not is_gold_linker_available():
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
stderr = subprocess.PIPE)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319525 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@315507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Check that the symbol sets exported by the minimal runtime and the full
runtime match (making exceptions for special cases as needed).
This test uses some possibly non-standard nm options, and needs to
inspect the symbols in runtime dylibs. I haven't found a portable way to
do this, so it's limited to x86-64/Darwin for now.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313615 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This eliminates a few inconsistencies between the symbol sets exported
by RTUBSan and RTUBSan_minimal:
* Handlers for nonnull_return were missing from the minimal RT, and
are now added in.
* The minimal runtime exported recoverable handlers for
builtin_unreachable and missing_return. These are not supposed to
exist, and are now removed.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313614 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts r313189, and adds a use of darwin_filter_host_archs() for
ubsan-minimal.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313206 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We're seeing strange issues on the public GreenDragon Darwin bots which
we don't understand. x86_64h tests are still being run on pre-Haswell
bots despite the added checks in test/ubsan_minimal/lit.common.cfg,
which were verified on our internal bots.
I'm unable to ssh into the affected public bot, so for now am trying a
more aggressive check which disables all x86_64h testing for
ubsan-minimal on Darwin.
rdar://problem/34409349
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Checking if config.target_arch is x86_64h doesn't work (the 'h' suffix
is dropped here, and I didn't account for that). Instead, check to see
if '-arch x86_64h' is in the cflags.
Tested on a pre-Haswell bot.
rdar://problem/34378605
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313053 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312982 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Testing: check-ubsan-minimal
Differential Revision: https://reviews.llvm.org/D37646
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Otherwise llvm-lit -v prints this:
PASS: <unnamed> :: TestCases/recover-dedup-limit.cpp (1 of 3)
PASS: <unnamed> :: TestCases/recover-dedup.cpp (2 of 3)
PASS: <unnamed> :: TestCases/uadd-overflow.cpp (3 of 3)
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312203 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Should un-break this bot:
http://green.lab.llvm.org/green//job/clang-stage1-configure-RA_build/38264/consoleFull
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312036 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
An implementation of ubsan runtime library suitable for use in production.
Minimal attack surface.
* No stack traces.
* Definitely no C++ demangling.
* No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general.
* as simple as possible
Minimal CPU and RAM overhead.
* Source locations unnecessary in the presence of (split) debug info.
* Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at.
* above two items save 3% binary size.
When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt.
Reviewers: pcc, kcc
Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D36810
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312029 91177308-0d34-0410-b5e6-96231b3b80d8
|
