Release 40 #1

slthakur · 2017-07-11T08:26:33Z

No description provided.

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@291819 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r293120 | compnerd | 2017-01-25 16:37:55 -0800 (Wed, 25 Jan 2017) | 3 lines builtins: remove an errant ':' Thanks to Dave Lee for pointing this out! ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@293191 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r292517 | rserge | 2017-01-19 12:27:11 -0800 (Thu, 19 Jan 2017) | 14 lines [XRay][Arm] Enable back XRay testing on Arm32 and fix the failing tests Summary: Testing of XRay was occasionally disabled on 32-bit Arm targets (someone assumed that XRay was supported on 64-bit targets only). This patch should fix that problem. Also here the instruction&data cache incoherency problem is fixed, because it may be causing a test to fail. This patch is one of a series: see also - https://reviews.llvm.org/D28624 Reviewers: dberris, rengolin Reviewed By: rengolin Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown Differential Revision: https://reviews.llvm.org/D28623 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@293296 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r293536 | dim | 2017-01-30 11:06:13 -0800 (Mon, 30 Jan 2017) | 27 lines Recommit: Stop intercepting some malloc-related functions on FreeBSD and macOS Summary: In https://bugs.freebsd.org/215125 I was notified that some configure scripts attempt to test for the Linux-specific `mallinfo` and `mallopt` functions by compiling and linking small programs which references the functions, and observing whether that results in errors. FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so normally these tests would fail, but when sanitizers are enabled, they incorrectly succeed, because the sanitizers define interceptors for these functions. This also applies to some other malloc-related functions, such as `memalign`, `pvalloc` and `cfree`. Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`, `pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers. Also delete the non-functional `cfree` wrapper for Windows, to fix the test cases on that platform. Reviewers: emaste, kcc, rnk Subscribers: timurrrr, eugenis, hans, joerg, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D27654 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@293917 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r294886 | weimingz | 2017-02-11 21:10:25 -0800 (Sat, 11 Feb 2017) | 9 lines [Builtin][ARM] Fix subsf3vfp for non-HF target Reviewers: rengolin, compnerd Reviewed By: compnerd Subscribers: hans, aemerson Differential Revision: https://reviews.llvm.org/D29869 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@295074 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r294806 | dim | 2017-02-11 00:48:40 +0100 (Sat, 11 Feb 2017) | 15 lines Remove struct_rtentry_sz on FreeBSD Summary: Since struct rtentry is an internal kernel-only structure on FreeBSD, and SIOCADDRT and SIOCDELRT are not supported anyway, stop including socketvar.h and attempting to get at the definition of struct rtentry, and move the line with struct_rtentry_sz to the SANIZER_LINUX block. Reviewers: kcc, kutuzov.viktor.84, emaste Reviewed By: kcc, emaste Subscribers: emaste, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D29832 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@295095 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r294425 | mgorny | 2017-02-08 00:43:44 -0800 (Wed, 08 Feb 2017) | 3 lines [test] Enable the strace_test only if strace is installed Differential Revision: https://reviews.llvm.org/D29628 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@295216 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r292257 | mgorny | 2017-01-17 13:08:25 -0800 (Tue, 17 Jan 2017) | 17 lines [test] [builtins] Remove obsolete/UB tests in __fixuns?fdi based Remove the failing tests for __fixunssfdi() and __fixunsdfdi() that relied on undefined (and most likely obsolete in terms of compiler-rt implementation behavior). Both tests presumed that 0x1.p+64 would be converted to 0xFFFFFFFFFFFFFFFFLL, that is the largest value in uint64 range. However, the C/C++ standards do not specify the behavior for converting a floating-point value to an integer of smaller range, and in this case both libgcc and compiler-rt implementations return 0 instead. Since the current behavior is correct with regards to standards and there is no good way of expressing 0xFFFFFFFFFFFFFFFFLL in single- or double-precision float, I've removed the failing test altogether. Differential Revision: https://reviews.llvm.org/D28146 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@295217 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r292729 | mgorny | 2017-01-21 13:55:00 -0800 (Sat, 21 Jan 2017) | 17 lines [test] Fix page address logic in clear_cache_test Fix the logic used to calculate page boundaries in clear_cache_test to use correct masks -- e.g. -4096 rather than -4095. The latter gives incorrect result since: -4095 -> 0xfffff001 -4096 -> 0xfffff000 (== ~4095) The issue went unnoticed so far because the array alignment caused the last bit not to be set. However, on 32-bit x86 no such alignment is enforced and the wrong page address caused the test to fail. Furthermore, obtain the page size from the system instead of hardcoding 4096. Differential Revision: https://reviews.llvm.org/D28849 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@295218 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------ r302639 | azanella | 2017-05-10 13:18:25 +0100 (Wed, 10 May 2017) | 11 lines [msan] Fix getmntent{_r} for empty /etc/fstab Some configuration (for instance default docker ubuntu images) uses a default empty and invalid /etc/fstab configuration file. It makes any call to getmntent return NULL and it leads to failures on Msan-aarch64{-with-call}-Test/MemorySanitizer.getmntent{_r}. This patch fixes it by creating a temporary file with some valid entries (although not valid for the system) to use along with setmntent/getmntent. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@303146 91177308-0d34-0410-b5e6-96231b3b80d8

sylvestre · 2017-07-11T17:39:49Z

we use https://reviews.llvm.org/

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>) llvm-mirror#1 0x7da5e1d1 in __asan::GetStackTraceWithPcBpAndContext(__sanitizer::BufferedStackTrace*, unsigned long, unsigned long, unsigned long, void*, bool) ../../../../../libsanitizer/asan/asan_stack.h:50 llvm-mirror#2 0x7da5e1d1 in __asan::ErrorGeneric::Print() ../../../../../libsanitizer/asan/asan_errors.cc:482 llvm-mirror#3 0x7db178d5 in __asan::ErrorDescription::Print() ../../../../../libsanitizer/asan/asan_errors.h:360 llvm-mirror#4 0x7db178d5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() ../../../../../libsanitizer/asan/asan_report.cc:167 llvm-mirror#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 llvm-mirror#6 0x7dadb14f in __interceptor_memcmp ../../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626 llvm-mirror#7 0x400cf5 in main /home/jakub/gcc/gcc/testsuite/c-c++-common/asan/memcmp-1.c:14 llvm-mirror#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

atos is apparently not able to resolve symbol addresses properly on i386-darwin reliably any more. This is causing bot flakiness: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/6841 There have not been any SDK changes on the bot as of late. /Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/llvm/projects/compiler-rt/test/asan/TestCases/Darwin/atos-symbolizer.cc:20:12: error: expected string not found in input // CHECK: llvm-mirror#1 0x{{.*}} in main {{.*}}atos-symbolizer.cc:[[@LINE-4]] ^ <stdin>:35:27: note: scanning from here #0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56) ^ <stdin>:35:27: note: with expression "@LINE-4" equal to "16" #0 0x112f56 in wrap_free (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/lib/clang/5.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:i386+0x56f56) ^ <stdin>:36:168: note: possible intended match here llvm-mirror#1 0xb6f20 in main (/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace/clang-build/tools/clang/runtime/compiler-rt-bins/test/asan/I386DarwinConfig/TestCases/Darwin/Output/atos-symbolizer.cc.tmp:i386+0x1f20) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@304674 91177308-0d34-0410-b5e6-96231b3b80d8

Merge 20170612

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

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

/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

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355013 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: This bug occurred when a plug-in requested that a binary not be symbolized while the script is trying to symbolize a stack frame. In this case `self.frame_no` would not be incremented. This would cause subsequent stack frames that are symbolized to be incorrectly numbered. To fix this `get_symbolized_lines()` has been modified to take an argument that indicates whether the stack frame counter should incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)` is now used in in the case where we don't want to symbolize a line so that we can keep the frame counter increment in a single function. A test case is included. The test uses a dummy plugin that always asks `asan_symbolize.py` script to not symbolize the first binary that the script asks about. Prior to the patch this would cause the output to script to look something like ``` #0 0x0 #0 0x0 in do_access #1 0x0 in main ``` rdar://problem/49476995 Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D65495 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368373 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: This bug occurred when a plug-in requested that a binary not be symbolized while the script is trying to symbolize a stack frame. In this case `self.frame_no` would not be incremented. This would cause subsequent stack frames that are symbolized to be incorrectly numbered. To fix this `get_symbolized_lines()` has been modified to take an argument that indicates whether the stack frame counter should incremented. In `process_line_posix()` `get_symbolized_lines(None, ...)` is now used in in the case where we don't want to symbolize a line so that we can keep the frame counter increment in a single function. A test case is included. The test uses a dummy plugin that always asks `asan_symbolize.py` script to not symbolize the first binary that the script asks about. Prior to the patch this would cause the output to script to look something like ``` #0 0x0 #0 0x0 in do_access #1 0x0 in main ``` This is the second attempt at landing this patch. The first (r368373) failed due to failing some android bots and so was reverted in r368472. The new test is now disabled for Android. It turns out that the patch also fails for iOS too so it is also disabled for that family of platforms too. rdar://problem/49476995 Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D65495 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368603 91177308-0d34-0410-b5e6-96231b3b80d8

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

zmodem and others added 10 commits January 12, 2017 21:25

Creating release_40 branch off revision 291814

850646e

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/branches/release_40@291819 91177308-0d34-0410-b5e6-96231b3b80d8

sylvestre closed this Jul 11, 2017

whchung pushed a commit to whchung/compiler-rt that referenced this pull request Oct 17, 2017

Merge pull request llvm-mirror#1 from scchan/merge_20170612

bd6798d

Merge 20170612

dtzWill pushed a commit that referenced this pull request Feb 27, 2019

Attempt to fix buildbot after r354972 [#1]. NFCI.

27dcec7

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355013 91177308-0d34-0410-b5e6-96231b3b80d8

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release 40 #1

Release 40 #1

slthakur commented Jul 11, 2017

sylvestre commented Jul 11, 2017

Release 40 #1

Release 40 #1

Conversation

slthakur commented Jul 11, 2017

sylvestre commented Jul 11, 2017