This repository was archived by the owner on Mar 28, 2020. It is now read-only.
[tsan] Disable sysroot flag on FreeBSD #2
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FreeBSD does not install a number of Clang-provided headers for the compiler in the base system due to incompatibilities between FreeBSD's and Clang's versions. As a workaround do not use --sysroot=. on FreeBSD until this is addressed. llvm.org/pr26651 Differential Revision: http://reviews.llvm.org/D17383 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@261229 91177308-0d34-0410-b5e6-96231b3b80d8
|
cc @vedantk, @kubabrecka |
|
Looks fine to me. |
|
🎩 |
gottesmm
pushed a commit
that referenced
this pull request
Jun 25, 2016
This should fail on frame #1 and show what that should actually be. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@271783 91177308-0d34-0410-b5e6-96231b3b80d8
gottesmm
pushed a commit
that referenced
this pull request
Sep 11, 2016
The stack trace produced by TSan on MIPS is:
Previous write of size 8 at 0x0120ed2930 by thread T1:
#0 memset
/home/slt/LLVM/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:678
(race_on_mutex.c.tmp+0x0120071808)
#1 __GI___pthread_mutex_init
/build/glibc-g99ldr/glibc-2.19/nptl/pthread_mutex_init.c:84
(libpthread.so.0+0x000000d634)
#2 <null>
/home/slt/LLVM/llvm/projects/compiler-rt/test/tsan/race_on_mutex.c:11 (race_on_mutex.c.tmp+0x01200ea59c)
Reviewers: samsonov, dvyukov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17796
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@263778 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Sep 20, 2016
Enable more ignores when we start crashing.
Unwind in CHECK SIGSEGVs if happens early:
FATAL: ThreadSanitizer CHECK failed: ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105 "((beg)) <= ((end))" (0x8000000000, 0x4000000000)
Program received signal SIGSEGV, Segmentation fault.
__tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true,
create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208
208 u32 idx0 = *meta;
(gdb) bt
#0 __tsan::MetaMap::GetAndLock (this=0x1337c88 <__tsan::ctx_placeholder+8>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true,
create=create@entry=true) at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:208
#1 0x00000000004a965f in __tsan::MetaMap::GetOrCreateAndLock (this=<optimized out>, thr=thr@entry=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992, write_lock=write_lock@entry=true)
at ../projects/compiler-rt/lib/tsan/rtl/tsan_sync.cc:198
#2 0x00000000004a162a in __tsan::Release (thr=0x7ffff7f91800, pc=pc@entry=4639488, addr=addr@entry=140737339086992) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:395
#3 0x000000000046cc40 in __interceptor_pthread_once (o=0x7ffff71a5890 <once_regsizes>, f=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1334
#4 0x00007ffff6f9fe86 in __gthread_once (__func=0x7ffff6f9d9c0 <init_dwarf_reg_size_table>, __once=0x7ffff71a5890 <once_regsizes>) at ./gthr-default.h:699
#5 uw_init_context_1 (context=context@entry=0x7fffffffd6d0, outer_cfa=outer_cfa@entry=0x7fffffffd980, outer_ra=0x437d13 <__sanitizer::BufferedStackTrace::SlowUnwindStack(unsigned long, unsigned int)+67>)
at ../../../src/libgcc/unwind-dw2.c:1572
#6 0x00007ffff6fa06a8 in _Unwind_Backtrace (trace=0x437c30 <__sanitizer::Unwind_Trace(_Unwind_Context*, void*)>, trace_argument=0x7fffffffd980) at ../../../src/libgcc/unwind.inc:283
#7 0x0000000000437d13 in __sanitizer::BufferedStackTrace::SlowUnwindStack (this=0x7ffff6103208, pc=pc@entry=4863574, max_depth=max_depth@entry=256)
at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:125
#8 0x0000000000434f4a in __sanitizer::BufferedStackTrace::Unwind (this=this@entry=0x7ffff6103208, max_depth=max_depth@entry=256, pc=pc@entry=4863574, bp=bp@entry=0, context=context@entry=0x0,
stack_top=stack_top@entry=0, stack_bottom=stack_bottom@entry=0, request_fast_unwind=request_fast_unwind@entry=false) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cc:76
#9 0x00000000004a36b3 in PrintCurrentStackSlow (pc=4863574) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:696
#10 __tsan::TsanCheckFailed (file=<optimized out>, line=<optimized out>, cond=<optimized out>, v1=<optimized out>, v2=<optimized out>) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl_report.cc:44
#11 0x000000000042dfd6 in __sanitizer::CheckFailed (file=file@entry=0x4b9fd0 "../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc", line=line@entry=105,
cond=cond@entry=0x4ba049 "((beg)) <= ((end))", v1=v1@entry=549755813888, v2=v2@entry=274877906944) at ../projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:79
#12 0x00000000004aa36c in ProtectRange (end=274877906944, beg=549755813888) at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:105
#13 __tsan::CheckAndProtect () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_posix.cc:133
#14 0x00000000004a9e95 in __tsan::InitializePlatform () at ../projects/compiler-rt/lib/tsan/rtl/tsan_platform_linux.cc:280
#15 0x0000000000497e73 in __tsan::Initialize (thr=0x7ffff7f91800) at ../projects/compiler-rt/lib/tsan/rtl/tsan_rtl.cc:343
#16 0x00007ffff7dea25a in _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffdb88, env=0x7fffffffdb98) at dl-init.c:111
#17 0x00007ffff7ddb30a in _dl_start_user () at rtld.c:871
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@281969 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Dec 3, 2016
…(Try #2) Summary: Unfortunately, there is no way to emit an llvm masked load/store in clang without optimizations, and AVX enabled. Unsure how we should go about making sure this test only runs if it's possible to execute AVX code. Reviewers: kcc, RKSimon, pgousseau Subscribers: kubabrecka, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D26506 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@288504 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Dec 3, 2016
…support (Try #2)" This reverts commit r288504. clang-bpf-build fails with no details: ******************** TEST 'AddressSanitizer-x86_64-linux :: TestCases/masked-ops.cpp' FAILED ******************** Script: -- /mnt/buildbot/slave-root/clang-bpf-build/stage1/./bin/clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m64 -o /mnt/buildbot/slave-root/clang-bpf-build/stage1/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/masked-ops.cpp.tmp /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp -mavx -O1 not /mnt/buildbot/slave-root/clang-bpf-build/stage1/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/masked-ops.cpp.tmp l1 2>&1 | FileCheck -check-prefix=CHECK-L1 /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp /mnt/buildbot/slave-root/clang-bpf-build/stage1/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/masked-ops.cpp.tmp l6 2>&1 | FileCheck -check-prefix=CHECK-L6 /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp /mnt/buildbot/slave-root/clang-bpf-build/stage1/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/masked-ops.cpp.tmp la 2>&1 | FileCheck -check-prefix=CHECK-LA /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp not /mnt/buildbot/slave-root/clang-bpf-build/stage1/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/masked-ops.cpp.tmp s1 2>&1 | FileCheck -check-prefix=CHECK-S1 /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp /mnt/buildbot/slave-root/clang-bpf-build/stage1/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/masked-ops.cpp.tmp s6 2>&1 | FileCheck -check-prefix=CHECK-S6 /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp /mnt/buildbot/slave-root/clang-bpf-build/stage1/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/masked-ops.cpp.tmp sa 2>&1 | FileCheck -check-prefix=CHECK-SA /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp -- Exit Code: 2 Command Output (stderr): -- FileCheck error: '-' is empty. FileCheck command line: FileCheck -check-prefix=CHECK-L6 /mnt/buildbot/slave-root/clang-bpf-build/llvm/projects/compiler-rt/test/asan/TestCases/masked-ops.cpp -- ******************** git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@288507 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Feb 11, 2017
Summary:
GET_CALLER_PC doesn't work properly on 31-bit s390, as pointers are 31-bit, the MSB bit can be set when the return address is copied into integer.
This causes e.g. errors like:
#0 0xfdadb129 (<unknown module>)
#1 0x7da5e1d1 in __asan::GetStackTraceWithPcBpAndContext(__sanitizer::BufferedStackTrace*, unsigned long, unsigned long, unsigned long, void*, bool) ../../../../../libsanitizer/asan/asan_stack.h:50
#2 0x7da5e1d1 in __asan::ErrorGeneric::Print() ../../../../../libsanitizer/asan/asan_errors.cc:482
#3 0x7db178d5 in __asan::ErrorDescription::Print() ../../../../../libsanitizer/asan/asan_errors.h:360
#4 0x7db178d5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() ../../../../../libsanitizer/asan/asan_report.cc:167
#5 0x7db178d5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ../../../../../libsanitizer/asan/asan_report.cc:397
#6 0x7dadb14f in __interceptor_memcmp ../../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626
#7 0x400cf5 in main /home/jakub/gcc/gcc/testsuite/c-c++-common/asan/memcmp-1.c:14
#8 0x7d807215 in __libc_start_main (/lib/libc.so.6+0x1a215)
#9 0x4007ed (/home/jakub/gcc/obj/gcc/testsuite/memcmp-1.exe+0x4007ed)
The actual return PC inside __interceptor_memcmp was 0x7dadb129 rather than 0xfdadb129.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29824
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@294793 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jul 28, 2017
This patch addresses two issues: Most of the time, hacks with `if/else` in order to get support for multi-configuration builds are superfluous. The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it expands to `.` on all single-configuration builds, and to a configuration name otherwise. The `if/else` hacks for the library name generation should also not be done, as CMake has `TARGET_FILE` generator expression precisely for this purpose, as it expands to the exact filename of the resulting target. Differential Revision: https://reviews.llvm.org/D35952 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309341 91177308-0d34-0410-b5e6-96231b3b80d8
cheshire
pushed a commit
to cheshire/swift-compiler-rt
that referenced
this pull request
Aug 28, 2017
This patch addresses two issues: Most of the time, hacks with `if/else` in order to get support for multi-configuration builds are superfluous. The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it expands to `.` on all single-configuration builds, and to a configuration name otherwise. The `if/else` hacks for the library name generation should also not be done, as CMake has `TARGET_FILE` generator expression precisely for this purpose, as it expands to the exact filename of the resulting target. Differential Revision: https://reviews.llvm.org/D35952 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309341 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Dec 21, 2017
Summary: __builtin_clz used for Log calculation returns an undefined result when argument is 0. I noticed that issue when was testing some fuzzers: ``` /src/libfuzzer/FuzzerTracePC.h:282:33: runtime error: shift exponent 450349 is too large for 32-bit type 'uint32_t' (aka 'unsigned int') #0 0x43d83f in operator() /src/libfuzzer/FuzzerTracePC.h:283:33 #1 0x43d83f in void fuzzer::TracePC::CollectFeatures<fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*)::$_1>(fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*)::$_1) const /src/libfuzzer/FuzzerTracePC.h:290 #2 0x43cbd4 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:445:7 #3 0x43e5f1 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:706:5 #4 0x43e9e1 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:739:3 #5 0x432f8c in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:754:6 #6 0x42ee18 in main /src/libfuzzer/FuzzerMain.cpp:20:10 #7 0x7f17ffeb182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #8 0x407838 in _start (/out/rotate_fuzzer+0x407838) Reviewers: kcc Reviewed By: kcc Subscribers: llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D41457 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@321211 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jun 11, 2018
Summary:
Running sanitized 32-bit x86 programs on glibc 2.27 crashes at startup, with:
ERROR: AddressSanitizer: SEGV on unknown address 0xf7a8a250 (pc 0xf7f807f4 bp 0xff969fc8 sp 0xff969f7c T16777215)
The signal is caused by a WRITE memory access.
#0 0xf7f807f3 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x127f3)
#1 0xf7a92599 (/lib/libasan.so.5+0x112599)
#2 0xf7a80737 (/lib/libasan.so.5+0x100737)
#3 0xf7f7e14f in _dl_init (/lib/ld-linux.so.2+0x1014f)
#4 0xf7f6eb49 (/lib/ld-linux.so.2+0xb49)
The problem is that glibc changed the calling convention for the GLIBC_PRIVATE
symbol that sanitizer uses (even when it should not, GLIBC_PRIVATE is exactly
for symbols that can change at any time, be removed etc.), see
https://sourceware.org/ml/libc-alpha/2017-08/msg00497.html
Fixes google/sanitizers#954
Patch By: Jakub Jelinek
Reviewed By: vitalybuka, Lekensteyn
Differential Revison: https://reviews.llvm.org/D44623
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@334363 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Feb 27, 2019
/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/compiler-rt/test/asan/TestCases/Posix/bcmp_test.cc:14:12: error: CHECK: expected string not found in input
// CHECK: {{#1.*bcmp}}
^
<stdin>:2:57: note: scanning from here
==34677==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffee93777c4 at pc 0x0001068a7285 bp 0x7ffee9377770 sp 0x7ffee9376ef8
^
<stdin>:6:20: note: possible intended match here
#2 0x106888e77 in main bcmp_test.cc:12
^
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354888 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jun 18, 2019
…latforms. Attempt #2. Summary: The main problem here is that `-*-version_min=` was not being passed to the compiler when building test cases. This can cause problems when testing on devices running older OSs because Clang would previously assume the minimum deployment target is the the latest OS in the SDK which could be much newer than what the device is running. Previously the generated value looked like this: `-arch arm64 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` With this change it now looks like: `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` This mirrors the setting of `config.target_cflags` on macOS. This change is made for ASan, LibFuzzer, TSan, and UBSan. To implement this a new `get_test_cflags_for_apple_platform()` function has been added that when given an Apple platform name and architecture returns a string containing the C compiler flags to use when building tests. This also calls a new helper function `is_valid_apple_platform()` that validates Apple platform names. This is the second attempt at landing the patch. The first attempt (r359305) had to be reverted (r359327) due to a buildbot failure. The problem was that calling `get_test_cflags_for_apple_platform()` can trigger a CMake error if the provided architecture is not supported by the current CMake configuration. Previously, this could be triggered by passing `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were generating test configurations for a list of architectures without checking if the relevant Sanitizer actually supported that architecture. We now intersect the list of architectures for an Apple platform with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer name) to iterate through the correct list of architectures. rdar://problem/50124489 Reviewers: kubamracek, yln, vsk, juliehockett, phosek Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D61242 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363633 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jun 19, 2019
…on-macOS Apple platforms. Attempt #2." This caused Chromium's clang package to stop building, see comment on https://reviews.llvm.org/D61242 for details. > Summary: > The main problem here is that `-*-version_min=` was not being passed to > the compiler when building test cases. This can cause problems when > testing on devices running older OSs because Clang would previously > assume the minimum deployment target is the the latest OS in the SDK > which could be much newer than what the device is running. > > Previously the generated value looked like this: > > `-arch arm64 -isysroot > <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` > > With this change it now looks like: > > `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot > <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` > > This mirrors the setting of `config.target_cflags` on macOS. > > This change is made for ASan, LibFuzzer, TSan, and UBSan. > > To implement this a new `get_test_cflags_for_apple_platform()` function > has been added that when given an Apple platform name and architecture > returns a string containing the C compiler flags to use when building > tests. This also calls a new helper function `is_valid_apple_platform()` > that validates Apple platform names. > > This is the second attempt at landing the patch. The first attempt (r359305) > had to be reverted (r359327) due to a buildbot failure. The problem was > that calling `get_test_cflags_for_apple_platform()` can trigger a CMake > error if the provided architecture is not supported by the current > CMake configuration. Previously, this could be triggered by passing > `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were > generating test configurations for a list of architectures without > checking if the relevant Sanitizer actually supported that architecture. > We now intersect the list of architectures for an Apple platform > with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer > name) to iterate through the correct list of architectures. > > rdar://problem/50124489 > > Reviewers: kubamracek, yln, vsk, juliehockett, phosek > > Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits > > Tags: #llvm, #sanitizers > > Differential Revision: https://reviews.llvm.org/D61242 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363779 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Jul 3, 2019
against CXX compiler ID instead of CRT test ID. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@364975 91177308-0d34-0410-b5e6-96231b3b80d8
fredriss
pushed a commit
that referenced
this pull request
Aug 13, 2019
Summary: feature coverage is a useful signal that is available during the merge process, but was not printed previously. Output example: ``` $ ./fuzzer -use_value_profile=1 -merge=1 new_corpus/ seed_corpus/ INFO: Seed: 1676551929 INFO: Loaded 1 modules (2380 inline 8-bit counters): 2380 [0x90d180, 0x90dacc), INFO: Loaded 1 PC tables (2380 PCs): 2380 [0x684018,0x68d4d8), MERGE-OUTER: 180 files, 78 in the initial corpus MERGE-OUTER: attempt 1 INFO: Seed: 1676574577 INFO: Loaded 1 modules (2380 inline 8-bit counters): 2380 [0x90d180, 0x90dacc), INFO: Loaded 1 PC tables (2380 PCs): 2380 [0x684018,0x68d4d8), INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 1048576 bytes MERGE-INNER: using the control file '/tmp/libFuzzerTemp.111754.txt' MERGE-INNER: 180 total files; 0 processed earlier; will process 180 files now #1 pulse cov: 134 ft: 330 exec/s: 0 rss: 37Mb #2 pulse cov: 142 ft: 462 exec/s: 0 rss: 38Mb #4 pulse cov: 152 ft: 651 exec/s: 0 rss: 38Mb #8 pulse cov: 152 ft: 943 exec/s: 0 rss: 38Mb #16 pulse cov: 520 ft: 2783 exec/s: 0 rss: 39Mb #32 pulse cov: 552 ft: 3280 exec/s: 0 rss: 41Mb #64 pulse cov: 576 ft: 3641 exec/s: 0 rss: 50Mb #78 LOADED cov: 602 ft: 3936 exec/s: 0 rss: 88Mb #128 pulse cov: 611 ft: 3996 exec/s: 0 rss: 93Mb #180 DONE cov: 611 ft: 4016 exec/s: 0 rss: 155Mb MERGE-OUTER: succesfull in 1 attempt(s) MERGE-OUTER: the control file has 39741 bytes MERGE-OUTER: consumed 0Mb (37Mb rss) to parse the control file MERGE-OUTER: 9 new files with 80 new features added; 9 new coverage edges ``` Reviewers: hctim, morehouse Reviewed By: morehouse Subscribers: delcypher, #sanitizers, llvm-commits, kcc Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D66030 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368617 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Would it be possible to cherry pick this commit from stable-next? Right now you can't compile the swift fork of compiler-rt on FreeBSD: