This repository has been archived by the owner on May 21, 2019. It is now read-only.
Support of SJ/LJ unwinding (for iOS) #1
Closed
Conversation
This file contains 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
|
Have you gotten unwinding to work in the compiler with this patch applied to compiler-rt? If you're still working on the compiler support it may be best to wait to merge this. I thought that there was extra support needed for SJLJ exceptions, but I'm also not that familiar with it. |
|
Yep, it works pretty fine (tested on device) and doesn't need any additional patches to LLVM itself. The only problem so far is that maintainer randomly appears/disappears and postpones review process - last time I've heard from him previous Friday and he promised to review on Monday but... :) |
|
Ok, I've pushed this to a branch: https://github.com/rust-lang/compiler-rt/tree/rust-2014-05-20-do-not-delete |
alexcrichton
pushed a commit
that referenced
this pull request
Aug 30, 2015
…bolizer on OSX 10.9 On OS X 10.9 /usr/bin/atos prints the following warning upon invocation: -- Warning: /usr/bin/atos is moving and will be removed from a future OS X release. It is now available in the Xcode developer tools to be invoked via: `xcrun atos` To silence this warning, pass the '-d' command-line flag to this tool. -- AtosSymbolizer treats the warning as the symbolization result for the first PC passed to the symbolizer. As a result, for each of the following PCs the file:line info for the previous PC is printed, e.g.: ==97926==ERROR: AddressSanitizer: attempting double-free on 0x60200000dfb0 in thread T0: ==97926==Using atos at user-specified path: /usr/bin/atos ==97926==Using dladdr symbolizer. #0 0x1007407e0 in -- (+0x427e0) #1 0x1006f6f25 in wrap_free asan_malloc_mac.cc:114 #2 0x7fff916e05fc in main atos-symbolizer.cc:17 #3 0x0 (<unknown module>) Unfortunately atos doesn't accept the -d switch on OSX versions other than 10.9, thus we have to check for the OSX version. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@233180 91177308-0d34-0410-b5e6-96231b3b80d8
alexcrichton
pushed a commit
that referenced
this pull request
Aug 30, 2015
Summary: On PPC64, half the msan tests fail with an infinite recursion through GetStackTrace like this: #0 __msan::GetStackTrace #1 __msan_memcpy #2 ?? () from /lib64/libgcc_s.so.1 #3 ?? () from /lib64/libgcc_s.so.1 #4 _Unwind_Backtrace #5 __sanitizer::BufferedStackTrace::SlowUnwindStack #6 __sanitizer::BufferedStackTrace::Unwind #7 __msan::GetStackTrace #8 __interceptor_calloc #9 _dl_allocate_tls #10 pthread_create@@GLIBC_2.17 #11 __interceptor_pthread_create #12 main The problem is that we call _Unwind_Backtrace to get a stack trace; but _Unwind_Backtrace calls memcpy, which we intercept and try to get another stack trace. This patch fixes it in __msan_memcpy by skipping the stack trace if IsInSymbolizer(). This works because GetStackTrace already creates a SymbolizerScope to "block reports from our interceptors during _Unwind_Backtrace". Reviewers: samsonov, wschmidt, eugenis Reviewed By: eugenis Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10762 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@240878 91177308-0d34-0410-b5e6-96231b3b80d8
alexcrichton
pushed a commit
that referenced
this pull request
Oct 23, 2015
Patch by Maxim Ostapenko!
Summary:
Right now, Addr2Line symbolizer in asan_symbolize.py doesn't support inline functions symbolization. This might be a useful feature for using ASan on embedded systems.
Test results:
$ cat test.c
static inline void FooBarBaz() {
__sanitizer_print_stack_trace();
}
int main() {
FooBarBaz();
return 0;
}
$ clang test.c -fsanitize=address -g -O2 -o test.x && ./test.x &> /tmp/test.log
$ ./projects/compiler-rt/lib/asan/scripts/asan_symbolize.py -l /tmp/test.log
#0 0x42095e in __sanitizer_print_stack_trace _asan_rtl_
#1 0x4cec07 in FooBarBaz /home/max/build/llvm/asan/test.c:4
#2 0x4cec07 in main /home/max/build/llvm/asan/test.c:8
#3 0x7f89f0891ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287
Reviewers: glider, samsonov
Subscribers: jevinskie, llvm-commits, ygribov
Differential Revision: http://reviews.llvm.org/D12153
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@247642 91177308-0d34-0410-b5e6-96231b3b80d8
timonvo
pushed a commit
to timonvo/compiler-rt
that referenced
this pull request
Apr 4, 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)
rust-lang#1 __GI___pthread_mutex_init
/build/glibc-g99ldr/glibc-2.19/nptl/pthread_mutex_init.c:84
(libpthread.so.0+0x000000d634)
rust-lang#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
alexcrichton
pushed a commit
that referenced
this pull request
Jul 18, 2016
c:\lipo\work\asan\b_llvm>c:\lipo\work\asan\b_llvm\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\null_deref.cc.tmp
=================================================================
==5488==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000028 (pc 0x7ff701f91067 bp 0x000c8cf8fbf0 sp 0x000c8cf8fbb0 T0)
==5488==The signal is caused by a READ memory access.
==5488==Hint: address points to the zero page.
#0 0x7ff701f91066 in NullDeref(int *) C:\lipo\work\asan\llvm\projects\compiler-rt\test\asan\TestCases\null_deref.cc:15:10
#1 0x8a0388830a67 (<unknown module>)
The reason was symbols was not initilized. In fact, it was first inited
with a call to stack.Print(), which calls
WinSymbolizerTool::SymbolizePC, then InitializeDbgHelpIfNeeded().
Since the StackWalk was performed before the stack.Print(), stack frames
where not gathered correctly.
There should be a better place to initialize symbols. For now, this
patch makes the test happy.
Patch by Wei Wang
Differential Revision: https://reviews.llvm.org/D22410
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@275580 91177308-0d34-0410-b5e6-96231b3b80d8
TimNN
pushed a commit
that referenced
this pull request
Apr 13, 2017
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
TimNN
pushed a commit
that referenced
this pull request
Jul 20, 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
TimNN
pushed a commit
that referenced
this pull request
Jul 20, 2017
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: #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 #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
alexcrichton
pushed a commit
that referenced
this pull request
Jan 25, 2018
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
alexcrichton
pushed a commit
to alexcrichton/compiler-rt
that referenced
this pull request
Jun 29, 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)
rust-lang#1 0xf7a92599 (/lib/libasan.so.5+0x112599)
rust-lang#2 0xf7a80737 (/lib/libasan.so.5+0x100737)
rust-lang#3 0xf7f7e14f in _dl_init (/lib/ld-linux.so.2+0x1014f)
rust-lang#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
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.
As feedback from compiler-rt is extremely slow and is always postponed to some distant future, here goes the simplest patch possible to allow SJ/LJ unwinding support which is required for supporting iOS. It's one of requirements to proceed with a new iOS related PR.