similar to: [LLVMdev] How to make sure llvm.memset intrinsic is not lowered into memset() call?

On 9/30/13 9:40 AM, Alexey Samsonov wrote: > Hi llvmdev! > > There are cases when we want our instrumentation passes for Sanitizer > tools to insert llvm.memset.* calls (basically, we want to mark > certain region of user memory as (un)addressable by writing magic > values for "shadow" of that memory region). llvm.memset are convenient: > (1) we don't have to

On Mon, Sep 30, 2013 at 7:48 PM, John Criswell <criswell at illinois.edu>wrote: > On 9/30/13 9:40 AM, Alexey Samsonov wrote: > > Hi llvmdev! > > There are cases when we want our instrumentation passes for Sanitizer > tools to insert llvm.memset.* calls (basically, we want to mark certain > region of user memory as (un)addressable by writing magic values for >

On 9/30/13 11:22 AM, Alexey Samsonov wrote: > > On Mon, Sep 30, 2013 at 7:48 PM, John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> wrote: > > On 9/30/13 9:40 AM, Alexey Samsonov wrote: >> Hi llvmdev! >> >> There are cases when we want our instrumentation passes for >> Sanitizer tools to insert

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Cool, can you use clang 3.3 then? :) > > I can, but digging deeper I see that the compiler-rt sanitizer tests > depend on just-built-clang for its object instrumentation. The next time > the instrumentation changes, I'd expect those tests to break. If the lit > tests that require

> What is the exact line you use to configure build tree, and the output you see? cmake ../.. \ -G Ninja \ -DCMAKE_INSTALL_PREFIX=ship \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_TARGETS_TO_BUILD=ARM \ -DLLVM_DEFAULT_TARGET_TRIPLE=arm-none-linux-gnueabi \ -DLLVM_TARGET_ARCH=arm-none-linux-gnueabi \ -DLLVM_LIT_ARGS=-v ninja check-all

The sanitizer common and asan that mention 'thread' are failing for me this morning. How are your bots looking? Last good commit here was 512c616cacf70ca029a2bf719a482b902f3687cd. > You could try preprocessing your report with perl or sed to fix paths > to your binaries. It would be great to have an option for that in > asan_symbolize.py. > > As for addr2line, we just

On Tue, Oct 29, 2013 at 10:55 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > What is the exact line you use to configure build tree, and the output > you see? > > cmake ../.. \ > -G Ninja \ > -DCMAKE_INSTALL_PREFIX=ship \ > -DCMAKE_BUILD_TYPE=Release \ > -DLLVM_ENABLE_ASSERTIONS=ON \ > -DLLVM_TARGETS_TO_BUILD=ARM \ >

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> > wrote: > > Hello! > > > > We want to implement in-process symbolizer for {Address,Thread}Sanitizer > > testing tools that would be based on LLVM libraries. > > I've noticed that llvm-nm

On Wed, May 29, 2013 at 5:40 PM, Greg Fitzgerald <garious at gmail.com> wrote: > For me, UBsan fails with clang 3.2 and passes with clang 3.3. > Cool, can you use clang 3.3 then? :) I think that the reason selected UBSan tests fail under clang 3.2 is a bug in Clang, which was fixed (Richard may correct me if I'm wrong). I don't really want to mark these tests as "failing

Hi all, compiler-rt is now not only a libgcc replacement for different platforms, there are sanitizer and profile runtimes as well. I plan to move the files as follows during this week: 1. libraries: a) all libgcc replacement stuff moves from "/lib" to "/lib/core" (the name sucks, please suggest alternatives). Same for platform-specific code:

Hello! We want to implement in-process symbolizer for {Address,Thread}Sanitizer testing tools that would be based on LLVM libraries. I've noticed that llvm-nm (as well as other tools) doesn't demangle C++ names. Is it true, that LLVM doesn't have the code that is capable of that, and if yes, are there any plans to add it? Depending on something like libiberty.a doesn't seem like a

In the same way that the core LLVM libraries have support routines for DWARF, I think that both mangling and demangling should be provided as well. I suspect that the 'Support' library is the best we have, although eventually we need to split this library up a bit. That's not really your problem though. The bigger problem is that we don't have any good way of sharing code between

On Thu, May 30, 2013 at 10:05 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The sanitizer common and asan that mention 'thread' are failing for me > this morning. How are your bots looking? Last good commit here was > 512c616cacf70ca029a2bf719a482b902f3687cd. > Hm, our bots seem to be green. Could you refer to guilty svn revision? > > > You could try

The trouble is that the sanitizer tests are not really compiler-rt tests. The original compiler-rt tests are, but not the sanitizer tests. The sanitizer tests are "compiler-rt tests via clang". The sanitizer runtime is a C++ library requiring only a C++ compiler to build it (and to *unit* test it). The ASan lit tests, however, require clang, because they are testing those C++

And one more question regarding ASan cmake build. Currently unittests are fine, but regular "clang -faddress-sanitizer" is not: current cmake build stores libclang_rt.asan-x86_64.a together with all the LLVM libs (in $build_path/lib/libclang_rt.asan-x86_64.a), but the Clang driver looks for asan runtime in clang resource dir:

On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> wrote: > Hello! > > We want to implement in-process symbolizer for {Address,Thread}Sanitizer > testing tools that would be based on LLVM libraries. > I've noticed that llvm-nm (as well as other tools) doesn't demangle C++ > names. Is it true, that LLVM doesn't have the code that is capable

Regarding Brad King's CMake patches for LLVM: http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173517 If compiler-rt could follow suit, the packaging for the toolchain becomes a nice, clean package-manager-friendly DAG. Currently, the compiler-rt CMake build depends on the just-built-clang to run its test suite. It's more intuitive to me that either: 1) compiler-rt's

On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Yes, at some point we definitely should introduce stubs as a last resort > for x86-64 relocations when the sections are too far apart, but I’d like to > avoid it whenever possible.**** > > ** ** > > What I meant in my previous message was that I’d have > RecordingMemoryManager use