search for: kfischer

Actually it only link the shlib fine. Linking any executable against it fails: llvm[2]: Linking Release+Asserts executable llvm-lto (without symbols) /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++ -fsanitize=address -O3 -Wl,-R -Wl,'$ORIGIN/../lib' -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Assert...

...ted dynamic libraries. > What I meant to say was that it worked for me on OS X on a slightly older > version of LLVM. Anyway, here's the ld line: > > "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id > --eh-frame-hdr -m elf_x86_64 -shared -o > /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/ > libLLVM-3.5svn.so/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o > /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o > -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Assert...

...o change the scope to be a DIFile instead so we'd get the correct file information. Unfortunately I had to revert this [1], because it crashes llvm's dwarf reader (which we use to get line information for backtraces when exceptions are thrown) with the following backtrace: isNULL at /Users/kfischer/Documents/julia-debug/deps/llvm-svn/lib/DebugInfo/DWARFDebugInfoEntry.h:52 getAddressRanges at /Users/kfischer/Documents/julia-debug/deps/llvm-svn/lib/DebugInfo/DWARFDebugInfoEntry.cpp:242 collectAddressRanges at /Users/kfischer/Documents/julia-debug/deps/llvm-svn/lib/DebugInfo/DWARFUnit.cpp:302 ge...

...ild llvm with asan enabled (I also updated to trunk, but not sure if that's related). However, it's totally possible that I missed a step that I took back when I set this up for me, so I might be doing something very stupid. Anyway, I'm configuring LLVM with ../configure --prefix=/home/kfischer/julia/usr --build=x86_64-pc-linux-gnu FC=gfortran CC="/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang -fsanitize=address" CXX="/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/bin/clang++" -fsanitize=address --disable-pr...

...ceLevelDebugging.html#block-descriptors > ) to describe file changes within a sequence of LLVM IR functions. > > A small example of IR would be easier to follow if you want help > debugging why your IR is causing problems. > > On Wed, Aug 13, 2014 at 2:25 PM, Keno Fischer > <kfischer at college.harvard.edu> wrote: >> Hello, >> >> I'm trying to fix a long standing issue we are having in Julia where >> when the file information switched, we weren't recording that >> correctly, so line information showed up in the wrong file. Basically >...

...ration side. While I come up with the IR, basically what I was doing was using a DebugLoc with scope being a DIFile rather than a DISubprogram as before. On Wed, Aug 13, 2014 at 7:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Aug 13, 2014 at 3:47 PM, Keno Fischer > <kfischer at college.harvard.edu> wrote: >> Sorry, I didn't have a small IR example and I was sure I was just >> doing something stupid. Thanks for the help, I'll try it out and >> report back. Maybe it would be good to add an assertion or something >> that tells people wha...

What I meant to say was that it worked for me on OS X on a slightly older version of LLVM. Anyway, here's the ld line: "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/ libLLVM-3.5svn.so/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib -L/home/k...

On Thu, Nov 21, 2013 at 6:18 AM, Keno Fischer <kfischer at csail.mit.edu> wrote: > Hello everybody, > > after moving from OS X to Linux build llvm with asan enabled Sorry, I failed to parse this. You're compiling Clang on Linux, and OSX is unrelated, right? > (I also updated > to trunk, but not sure if that's related). However,...

...safely be linked to instrumented dynamic libraries. What I meant to say was that it worked for me on OS X on a slightly older version of LLVM. Anyway, here's the ld line: "/usr/bin/ld" -export-dynamic -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -shared -o /home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib/ libLLVM-3.5svn.so/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o -L/home/kfischer/julia/deps/llvm-svn/build_Release+Asserts+Sanitize/Release+Asserts/lib -L/home/k...

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the origin shadow > (or > > just a memset intrinsic?). > > Yes. There is an old bug for that o...

Looks like when you materialize the stores, you should check the size of the the store and emit an appropriate amount of stores to the origin shadow (or just a memset intrinsic?). On Wed, Feb 5, 2014 at 2:13 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The @entry stuff is just a gdb artifact. I've been tracking this back a > little further, and it seems there's at least an origin propagation problem: > > (gdb) list > 281 goto value_to_pointer_error; > 282 } > 283...

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 > LLVM global variable is generated with size 1000, while > kMsanParamTlsSizeInWords == 100, could there be some sort of overflow > happening? > > > On Sat, Feb 1, 2014...

I have verified that both TLS implementations indeed find the same area of memory. Anything else I could look for? On Tue, Jan 28, 2014 at 4:28 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > Yes, both JIT code and the native runtime are instrumented. I am under the > impressions that the the C library should guarantee that from the way the > relocations are implemented as long as both native and JITed code are on > the same thread (but I...

...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 sets up tls for 3. On Sun, Feb 2, 2014 at 10:39 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > I don't think we're doing anything unusual. Here's the relevant snippet from > the generated IR for ccall (after instrumentation): > > ccall: ; preds = %pass6, %113 > %114 = phi i8* [ %110, %...

...ed 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 > <kfischer at college.harvard.edu> wrote: >> 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 t...

...spect the issue is with MCJIT having to process a ton more relocations and code and being inefficient at it, but I can't prove that). That's not the issue however. Eventually, I get ==17150== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f417cea3189 in bitvector_any1 /home/kfischer/julia-san/src/support/bitvector.c:177 [ snip ] Uninitialized value was created by a heap allocation #0 0x7f41815de543 in __interceptor_malloc /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854 #1 0x7f417cc7d7f1 in alloc_big /home/kfischer/julia-...

...g, correct implementations of fabs, fneg, and copysign are built out of logical operations rather than arithmetic ones. > > I don’t know offhand why the behavior of multiplication of multiplication in APFloat was changed. > > —Owen > > On Aug 6, 2014, at 10:45 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > >> Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to >> 0-sNaN then though or does that not signal? Does that mean we need a >> separate way to handle negate in the IR? Funnily enough, historically >> I believe we we...

We don't currently apply any relocations (that I know of) for debug info in LLDB. > On Jun 2, 2014, at 12:35 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > I think I'm getting closer. The debug_info section is being relocated correctly (I think): > > 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000049) > > 0x00...

On Fri, May 22, 2015 at 4:14 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > This might be related to GOT relocations. I rewrote that part of > RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk? > I didn't notice that you were running 3.5 the first time I read this. Keno's diagnosis is very likely to...

...rceFormat negate(source) > sourceFormat abs(source) > > Multiplying by -1.0 has the potential to raise a floating point exception on sNaN inputs, and hence is not a valid implementation of negation per IEEE 754. > > —Owen > > On Aug 6, 2014, at 9:51 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > >> In r187314, APFloat multiplication by with NaNs was made to always >> yield a positive NaN. I am wondering whether that was the correct >> decision. It is of course true that the result of a multiplication is >> undefined in IEEE, ho...