search for: __msan_param_tls

The code for ccall looks right. Sounds like you have a very small range of instructions where an uninitialized value appear. You could try debugging at asm level. Shadow for b should be passed at offset 0 in __msan_param_tls. MSan could propagate shadow through arithmetic and even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized gets mixed in. Also, what is this @entry stuff? It looks like bitvector_any1 has 6 arguments, but your ccall snippet only s...

...< > eugeni.stepanov at gmail.com> wrote: > >> The code for ccall looks right. Sounds like you have a very small >> range of instructions where an uninitialized value appear. You could >> try debugging at asm level. Shadow for b should be passed at offset 0 >> in __msan_param_tls. >> >> MSan could propagate shadow through arithmetic and even some logic >> operations (like select). It could be that b is clean on function >> entry, but then something uninitialized gets mixed in. >> >> Also, what is this @entry stuff? It looks like bitvector...

...: > >>> > >>> The code for ccall looks right. Sounds like you have a very small > >>> range of instructions where an uninitialized value appear. You could > >>> try debugging at asm level. Shadow for b should be passed at offset 0 > >>> in __msan_param_tls. > >>> > >>> MSan could propagate shadow through arithmetic and even some logic > >>> operations (like select). It could be that b is clean on function > >>> entry, but then something uninitialized gets mixed in. > >>> > >>> Al...

...between JITted code and native helper >>>> functions. How are you handling them? Are native functions >>>> MSan-instrumented? >>>> MSan is passing shadow across function calls in TLS slots. Does your >>>> TLS implementation guarantee that accesses to __msan_param_tls from >>>> JITted and from native code map to the same memory? >>>> >>>> >>>> On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov >>>> <eugeni.stepanov at gmail.com> wrote: >>>> > This is really cool. I've not heard...

...strument 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 KASAN implementation. I kind of exp...

...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 KASAN imple...

I assume there are transitions between JITted code and native helper functions. How are you handling them? Are native functions MSan-instrumented? MSan is passing shadow across function calls in TLS slots. Does your TLS implementation guarantee that accesses to __msan_param_tls from JITted and from native code map to the same memory? On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > This is really cool. I've not heard of anyone using MSan with MSJIT before. > > > On Mon, Jan 27, 2014 at 7:44 PM, Keno Fischer...

...s 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 do...

...; I assume there are transitions between JITted code and native helper >> functions. How are you handling them? Are native functions >> MSan-instrumented? >> MSan is passing shadow across function calls in TLS slots. Does your >> TLS implementation guarantee that accesses to __msan_param_tls from >> JITted and from native code map to the same memory? >> >> >> On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov >> <eugeni.stepanov at gmail.com> wrote: >> > This is really cool. I've not heard of anyone using MSan with MSJIT >> before....

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

Hello everybody, I've run into some strange behavior with memory sanitizer that I can't explain and hope somebody with more knowledge of the implementation would be able to help me out or at least point me into the right direction. For background, I'm using memory sanitizer to check Julia (julialang.org), which uses (or at least will once I track down a few bugs) MCJIT for the code