similar to: [LLVMdev] So I just did a normal 'ninja check' with a CMake build that enables ASan and the go bindings tests are... busted...

On Tue, Sep 27, 2016 at 6:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > > On Sep 27, 2016, at 2:18 AM, Carsten Mattner <carstenmattner at gmail.com> > wrote: > > > >> On Mon, Sep 26, 2016 at 11:02 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> I'll either need to get a reproducer from you and/or try to repro

On Tue, Sep 27, 2016 at 6:33 PM, Teresa Johnson <tejohnson at google.com> wrote: > > I can't reproduce the failure. I am building with a clang built > Release from recent source as my stage-1 bootstrap compiler: > clang version 4.0.0 (trunk 282322) (llvm/trunk 282341) The clang I use was built from the 3.9 release branch: clang version 3.9.1 (branches/release_39

Hi, I am seeing an LLVM build failure with recent LLD on x86 like: [...] lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a lib/libLLVMAgg ressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a lib/libLLVMAnalysis.a lib/libLLVMProfil eData.a

Hey, So in Fedora rawhide we are now building llvm 3.7.1 into the lots of little shared libraries format. However I'm running into a major problem with the fact that sometimes dlclose isn't dropping all the LLVM libraries from the address space of the process. We have a sequence like this: a) X server asks mesa gbm library to init, it loads the kms_swrast_dri.so with

Hi, I have a debug build with shared libraries (to reduce compilation time), but since yesterday, it's failing with an ExecutionEngine error: FAILED: : && /usr/lib/ccache/bin/c++ -fPIC -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11

hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with gcc-4.5.3, binutils-2.21.1, glibc-2.12.2 . As this suggestion: http://llvm.org/bugs/show_bug.cgi?id=10969 I applied a patch like this one: --- llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h 2011-07-26 01:24:55.000000000 +0200 +++ llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h

On Tue, Sep 27, 2016 at 8:37 PM, Teresa Johnson <tejohnson at google.com> wrote: Just in case it's important, I'm using Arch Linux (and most Linux distros these days) CFLAGS/CPPFLAGS/LDFLAGS, which are as follows: $ grep FLAGS /etc/makepkg.conf CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"

Nico, There is a third place that '#undef PPC' is needed (at the top of PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in your CPPFLAGS. I'll try to get this fixed in trunk shortly. -Hal On Fri, 2011-12-02 at 12:30 +0100, acrux_it at libero.it wrote: > hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with > gcc-4.5.3, binutils-2.21.1,

On Fri, 2011-12-02 at 06:58 -0600, Hal Finkel wrote: > Nico, > > There is a third place that '#undef PPC' is needed (at the top of > PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in > your CPPFLAGS. I'll try to get this fixed in trunk shortly. I just tested this, and I was wrong: passing -UPPC to configure in CPPFLAGS does not work for some reason.

Hi,I am working with a custom built (LFS-based) Linux distro and am attempting to compile Samba4. Samba3 has always compiled without issue. The system has its Python installed in /opt/python2. There are symlinks to put "python" in /usr/local/bin and the "python2.7" lib folder in /usr/include. The configure command used was simply ./configure --enable-fhs --with-quotas The

Hello everybody, after moving from OS X to Linux build 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

On 10 October 2014 21:31, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > Sounds like an arm-thumb interworking veneer, generated by the linker... the > real function should be called 'asan_handle_no_return' (with some number of '_' > prefixing it. I don't remember how many get added). It is a veneer which has just a jump and a word after it, which

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/

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

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

Hello, I update my building scripts to build LLVM 4.0 RC1 (with clang, lldb, libc++, libc++abi, lld) on CentOS 6 and I got a lot of undefined symbols during linking LLDB. I'm using clang-3.9 and this configuration: -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++

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

Hi Kcc, I'm trying enabling the Asan in my firmware, but I find the asan instrumentation code size impact is too big for me. I just implement necessary firmware version runtime library functions (e.g. __asan_report_load8) with blank body firstly to pass the asan enabled build, but I find the new binary code size is already ~2.5 times as original one with asan disabled in GCC. I know Linux

On 04/10/2018 05:22 AM, Han Han wrote: > Hi, > I tried to compile libvirt with address sanitizer( > https://github.com/google/sanitizers/wiki/AddressSanitizer) to discover > memory errors. But fails when make. > Code version: > $ git describe > v4.2.0-92-g3f204e4de > > Compile tools: > automake 1:1.15.1-3 all [installed] > clang-7 1:7~svn323616-1 amd64

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