search for: __msan_retval_tls

...er: — still tries to partially instrument the blacklisted code; — does not check whether its global memory storage variables are already defined. The second issue, present in MemorySanitizer::initializeCallbacks, adds a second copy of storage global variables when compiling msan.cc (e.g. __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this results in an undefined reference during the linkage. Here the question is what was initially intended to be done. I know that compiling blacklisted asan runtime code with -fsanitize=address is just fine, and this is what Apple actually does in XNU KAS...

...ially instrument the blacklisted code; > — does not check whether its global memory storage variables are already > defined. > The second issue, present in MemorySanitizer::initializeCallbacks, adds a > second copy of storage global variables when compiling msan.cc (e.g. > __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this > results in an undefined reference during the linkage. > > Here the question is what was initially intended to be done. I know that > compiling blacklisted asan runtime code with -fsanitize=address is just > fine, and this is what Apple...

...blacklisted code; >> — does not check whether its global memory storage variables are already >> defined. >> The second issue, present in MemorySanitizer::initializeCallbacks, adds a >> second copy of storage global variables when compiling msan.cc (e.g. >> __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this >> results in an undefined reference during the linkage. >> >> Here the question is what was initially intended to be done. I know that >> compiling blacklisted asan runtime code with -fsanitize=address is just >> fine, an...

On Wed, Jul 13, 2016 at 04:48:51PM +0200, Sedat Dilek via llvm-dev wrote: > [ CCed all people who were involved in this thread ] > > Hi Tom, > > personally, I am interested to test the prebuilt-toolchains for > Ubuntu/xenial alias 16.04 LTS and Debian/Jessie v8.5.0 AMD64. > The available toolchains are incomplete and thus useless. > > Just as a fact: There is still no

...tr (i64 add (i64 ptrtoint ([1000 x i64]* > @__msan_param_tls to i64), i64 16) to i64*), align 8, !dbg !7 > store i32 0, i32* inttoptr (i64 add (i64 ptrtoint ([1000 x i32]* > @__msan_param_origin_tls to i64), i64 16) to i32*), align 4, !dbg !7 > store i32 0, i32* bitcast ([8 x i64]* @__msan_retval_tls to i32*), align > 8, !dbg !7 > %118 = call i32 %117(i32* %116, i64 %87, i64 %107), !dbg !7, !julia_type > !9 > > > > On Sun, Feb 2, 2014 at 6:18 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> > wrote: >> >> How is ccall() implemented? If it manually...

...64]* >> > @__msan_param_tls to i64), i64 16) to i64*), align 8, !dbg !7 >> > store i32 0, i32* inttoptr (i64 add (i64 ptrtoint ([1000 x i32]* >> > @__msan_param_origin_tls to i64), i64 16) to i32*), align 4, !dbg !7 >> > store i32 0, i32* bitcast ([8 x i64]* @__msan_retval_tls to i32*), >> align >> > 8, !dbg !7 >> > %118 = call i32 %117(i32* %116, i64 %87, i64 %107), !dbg !7, >> !julia_type >> > !9 >> > >> > >> > >> > On Sun, Feb 2, 2014 at 6:18 AM, Evgeniy Stepanov < >> eugeni.stepanov...

...param_tls to i64), i64 16) to i64*), align 8, !dbg !7 > >>> > store i32 0, i32* inttoptr (i64 add (i64 ptrtoint ([1000 x i32]* > >>> > @__msan_param_origin_tls to i64), i64 16) to i32*), align 4, !dbg !7 > >>> > store i32 0, i32* bitcast ([8 x i64]* @__msan_retval_tls to i32*), > >>> > align > >>> > 8, !dbg !7 > >>> > %118 = call i32 %117(i32* %116, i64 %87, i64 %107), !dbg !7, > >>> > !julia_type > >>> > !9 > >>> > > >>> > > >>> > > >&...

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the

...mpxchg i32* %p, i32 %a, i32 %b seq_cst + %0 = cmpxchg i32* %p, i32 %a, i32 %b seq_cst seq_cst ret i32 %0 } @@ -46,16 +46,16 @@ entry: ; CHECK: icmp ; CHECK: br ; CHECK: @__msan_warning -; CHECK: cmpxchg {{.*}} seq_cst +; CHECK: cmpxchg {{.*}} seq_cst seq_cst ; CHECK: store i32 0, {{.*}} @__msan_retval_tls ; CHECK: ret i32 -; relaxed cmpxchg: bump up to "release" +; relaxed cmpxchg: bump up to "release monotonic" define i32 @CmpxchgMonotonic(i32* %p, i32 %a, i32 %b) sanitize_memory { entry: - %0 = cmpxchg i32* %p, i32 %a, i32 %b monotonic + %0 = cmpxchg i32* %p, i32 %a,...