similar to: [LLVMdev] Building LLVM with asan

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/

Indeed, removing that flag works fine, the only question is why this is added in tools/llvm-shlib/Makefile in the first place then and what to do about it: ifeq ($(HOST_OS), $(filter $(HOST_OS), Linux GNU GNU/kFreeBSD)) # Don't allow unresolved symbols. LLVMLibsOptions += -Wl,--no-undefined endif On Thu, Nov 21, 2013 at 11:53 AM, Alexander Potapenko <glider at

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, it's totally possible > that I

Yeah, it's not linking the runtime because you're building a shared library. This is totally ok. In this case there are undefined __asan_* symbols that are resolved when an instrumented binary loads your library. What's wrong here is that some flag passed to ld prevents it from creating undefined symbols (--no-undefined?). This flag must be removed when building with ASan. This

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

This is partly an llvm question, and maybe partly C++. I am trying to make calls on code in the llvm infrastructure.(3.4.2) I appear to be missing some include files, but don't know how to track them down. I get compile errors on existing llvm header files, like the following two examples: -------------------------------------------------------------------------------- In file included

I'm trying to link a program with LLVM on Linux. I've managed to take out the test files from 'llvm-config --libs' but now it's getting errors with missing symbols. The same program successfully links with the same version of LLVM (3.8) on Windows, so it's not a problem with the code per se, it's some kind of configuration issue. Any ideas? g++ -std=c++11

Tried that just now, same result. On Fri, Mar 25, 2016 at 6:58 AM, Snehasish Kumar <kumar.snehasish at gmail.com> wrote: > Hi Russel, > > Can you try compiling aklo.o using -fno-rtti prior to linking? > > On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm trying to link a program with LLVM on Linux.

Hi Russel, Can you try compiling aklo.o using -fno-rtti prior to linking? On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm trying to link a program with LLVM on Linux. I've managed to take out > the test files from 'llvm-config --libs' but now it's getting errors with > missing symbols. The same program

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 we would always create a scope with the DISubprogram and the given line number. What I tried was to change the scope to be a DIFile instead so we'd get the correct file

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 what's wrong in this case, since the generated DWARF seems to be invalid? On Wed, Aug 13, 2014 at 5:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > Use

Yeah, seems to. a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv U _ZN4llvm4outsEv U _ZN4llvm4outsEv 0000000000000000 b _ZGVZN4llvm4outsEvE1S 0000000000000000 T _ZN4llvm4outsEv 0000000000000000 r _ZZN4llvm4outsEvE19__PRETTY_FUNCTION__ 0000000000000000 b _ZZN4llvm4outsEvE1S U _ZN4llvm4outsEv I can try building

Oh, I see. Sorry I misunderstood. I'll try to come up with some minimal IR. The assertion stems from the fact that getCompileUnitDIE() returns null and then crashes at DWARFUnit.cpp:301. I admit I don't know if this problem is on the parsing or the generation 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

Since the log tells you that llvm::outs() is not found, and since it is supposed to be found in libLLVMSupport.a, you can try: $ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv ... 0000000000002070 T __ZN4llvm4outsEv ... The output should have the symbol defined. -- Mehdi > On Mar 25, 2016, at 12:18 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U

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

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

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

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

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