search for: __msan_print_shadow

...le.com site, but it > has _never_ caused problems. I guess partial reads at a non-zero > offset are pretty uncommon, and also LLVM IR tends to use smaller > stores (larger ones are transformed to memset/memcpy and we handle > those correctly). Should be fixed anyway. > > Note that __msan_print_shadow can lie about origin a bit if the > address is not 4-byte aligned (it would print origins for aligned > locations instead). > > > > > > > On Wed, Feb 5, 2014 at 2:13 PM, Keno Fischer < > kfischer at college.harvard.edu> > > wrote: > >> > >&gt...

...type(jvt) && jl_tparam0(jvt) == jt) { > 285 void *ptr = jl_unbox_voidpointer(v); > 286 assert(__msan_test_shadow(&ptr,sizeof(void**)) == -1); > 287 return (void*)ptr; > 288 } > 289 } > 290 > (gdb) p __msan_print_shadow(v,16) > 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff > o: 40000e23 o: 40000e23 o: 40000e23 o: 40000e23 > $21 = void > (gdb) p __msan_print_shadow(&ptr,8) > ff ff ff ff ff ff ff ff > o: 40000e23 o: 80007614 > $22 = void > > Notice the origin of the lower bits...

...the debugger, I see (gdb) f 3 #3 0x00007f417cea318a in bitvector_any1 (b=0x60c000607240, b at entry=<optimized out>, offs=0, offs at entry=<optimized out>, nbits=256, nbits at entry=<optimized out>) at bitvector.c:177 177 if ((b[0] & mask) != 0) return 1; (gdb) p __msan_print_shadow(&b,8) ff ff ff ff ff ff ff ff o: 3f0010a6 o: 80007666 which seems to indicate that the local variable b has uninitialized data. I'm having a hard time believing that though, since if I look at the functions before it, the place where it's coming from is initialized: #4 0x00007f4175...

...gt; >>>> >> nbits=256, >> >>>> >> nbits at entry=<optimized out>) >> >>>> >> at bitvector.c:177 >> >>>> >> 177 if ((b[0] & mask) != 0) return 1; >> >>>> >> (gdb) p __msan_print_shadow(&b,8) >> >>>> >> ff ff ff ff ff ff ff ff >> >>>> >> o: 3f0010a6 o: 80007666 >> >>>> >> >> >>>> >> which seems to indicate that the local variable b has >> >>>> >> uninitiali...

...7cea318a in bitvector_any1 (b=0x60c000607240, >> b at entry=<optimized out>, offs=0, offs at entry=<optimized out>, nbits=256, >> nbits at entry=<optimized out>) >> at bitvector.c:177 >> 177 if ((b[0] & mask) != 0) return 1; >> (gdb) p __msan_print_shadow(&b,8) >> ff ff ff ff ff ff ff ff >> o: 3f0010a6 o: 80007666 >> >> which seems to indicate that the local variable b has uninitialized data. >> I'm having a hard time believing that though, since if I look at the >> functions before it, the place where i...

...>> b at entry=<optimized out>, offs=0, offs at entry=<optimized out>, >> nbits=256, >> >> nbits at entry=<optimized out>) >> >> at bitvector.c:177 >> >> 177 if ((b[0] & mask) != 0) return 1; >> >> (gdb) p __msan_print_shadow(&b,8) >> >> ff ff ff ff ff ff ff ff >> >> o: 3f0010a6 o: 80007666 >> >> >> >> which seems to indicate that the local variable b has uninitialized >> data. >> >> I'm having a hard time believing that though, since if I look...

...0, offs at entry=<optimized out>, >>>> >> nbits=256, >>>> >> nbits at entry=<optimized out>) >>>> >> at bitvector.c:177 >>>> >> 177 if ((b[0] & mask) != 0) return 1; >>>> >> (gdb) p __msan_print_shadow(&b,8) >>>> >> ff ff ff ff ff ff ff ff >>>> >> o: 3f0010a6 o: 80007666 >>>> >> >>>> >> which seems to indicate that the local variable b has uninitialized >>>> >> data. >>>> >> I'm h...

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