similar to: [LLVMdev] Sanitizers libs in Compiler-RT

On 30 January 2014 20:33, Reid Kleckner <rnk at google.com> wrote: > Basically, compiler-rt contains the only runtime libraries we ship with > Clang. The sanitizers are runtime libraries shipped with clang (they have > some version dependence), so they went in compiler-rt. Now they are > starting to feel much larger than compiler-rt, so perhaps they should be > split out.

> On Jan 30, 2014, at 1:50 PM, Reid Kleckner <rnk at google.com> wrote: > >> On Thu, Jan 30, 2014 at 1:19 PM, Renato Golin <renato.golin at linaro.org> wrote: >>> On 30 January 2014 20:33, Reid Kleckner <rnk at google.com> wrote: >>> Basically, compiler-rt contains the only runtime libraries we ship with Clang. The sanitizers are runtime libraries

On 30 January 2014 21:50, Reid Kleckner <rnk at google.com> wrote: > > I don't see any compelling reason to split the sanitizers out today. > Clear, next. I think the sanitizer guys would probably take a patch to CMakeLists.txt to > disable the sanitizer RTLs. > Right. I'll first make it build and test, than I'll disable via a flag, since other people can work

On Fri, Jan 31, 2014 at 1:47 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 31 January 2014 08:50, Alexey Samsonov <samsonov at google.com> wrote: > >> That is, I still don't see what the problem is - it's relatively easy to >> enable building just the compiler-rt library on ARM and not enable building >> sanitizers on ARM. >> > >

Chandler, Thanks for the great overview. On Fri, Jan 31, 2014 at 12:12 PM, Chandler Carruth <chandlerc at google.com>wrote: > > On Thu, Jan 30, 2014 at 1:54 PM, Renato Golin <renato.golin at linaro.org>wrote: > >> On 30 January 2014 21:50, Reid Kleckner <rnk at google.com> wrote: >>> >>> I don't see any compelling reason to split the

On 1 February 2014 00:44, Nick Kledzik <kledzik at apple.com> wrote: > * One of the interesting things about compiler-rt is the static library to > dynamic library migration (e.g. libgcc.a vs libgcc_s.so, or on Darwin > libclang_*.a vs libSystem.dylib). If the shared library ships > independently from the compiler, then the compiler may need a .a file that > can ship with it

The build for the Android sanitizers is unique in that it needs to link against the Android system libraries to create a shared object and its test suites. The current solution to build ASan is to drop the compiler-rt repo into the llvm source tree and cross-compile the llvm build for Android. This is a bit awkward for few reasons: 1) Not all of llvm can be cross-compiled for Android.

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++

Can anybody give me any pointer on how compiler-rt, especially the sanitizers work? Do they operate on IR as any other LLVM pass? Or are they integral part of the frontend itself? I couldn't spot any documentation on the internals of compiler-rt project? What happens (sequence of actions) when I pass -fsanitizer=dataflow to clang? Precisely, I intend to alter the behaviour of DFSan to suit my

> Alexey's approach with CMake sub-projects. I prefer that direction as well, but what I've proposed is a solution that works today. To support cross-compilation, we'll need to loop over each supported arch (llvm-config --targets-built), then loop over each supported triple for each arch (hard-coded map?), and then pair up each triple with a sysroot (system paths provided by the

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 Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > Hi Steven, > > This looks interesting and raises a number of questions :) > > 1) Does applying this patch actually bring working sanitizers to x32 > platform? > That is, after you build the clang, does "clang -fsanitize=whatever foo.c" > compile/link/run with expected results? > I doubt that, as

> Note that ASan tests on Android require llvm-symbolizer binary. That's a really good point. And I see that llvm-symbolizer can't just be pulled into compiler-rt because it has dependencies on DebugInfo, Object, and Support libraries. This throws a big wrench in Alexey's plan to have the native compiler-rt build generate the cross-compiled binaries for all supported targets. We

> I really like the property of libFuzzer living in its own place so that > it's easy to use without building the world But it’s not: the implementation of the coverage instrumentation is done in one of the sanitizers, so it’s impossible to just use libFuzzer without them. Furthermore, I would think that almost all libFuzzer users would use a sanitizer while fuzzing. I can see a few

On Fri, Jan 31, 2014 at 1:04 PM, Iain Sandoe <iain at codesourcery.com> wrote: > Hi Alexey, > > On 31 Jan 2014, at 08:50, Alexey Samsonov wrote: > > > Thanks for the great overview. > +1 > ( and +1 for David's comment about moving the unwind stuff into this area) > > > > > On Fri, Jan 31, 2014 at 12:12 PM, Chandler Carruth <chandlerc at

It does sound like Android is better suited for "honest" cross-compilation, rather than "build compiler-rt for all targets we can find" model. I'm still not convinced that we must require the "ninja install" step. Could we just "ninja clang" and then build the second stage against the first stage build directory? Will this "find_package" thing

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:

On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk>wrote: > On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > > Hi Steven, > > > > This looks interesting and raises a number of questions :) > > > > 1) Does applying this patch actually bring working sanitizers to x32 > > platform? > > That is, after you build the

Hi Greg, On Wed, Apr 2, 2014 at 2:50 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Alexey, Evgeniy, > > I propose the following steps to unify multi-arch support in compiler-rt: > > 1) The compiler-rt test suite adds "-L${CMAKE_CURRENT_BINARY_DIR}/lib" > to its 'clang' variables. This way we can test the sanitizers without > installing any libs

On 18/02/2015 23:29, Alexey Samsonov wrote: > > On Tue, Feb 17, 2015 at 6:23 PM, Anna Zaks <ganna at apple.com <mailto:ganna at apple.com>> wrote: > > >> On Feb 17, 2015, at 4:00 PM, Alexey Samsonov <vonosmas at gmail.com <mailto:vonosmas at gmail.com>> wrote: >> >> >> On Tue, Feb 17, 2015 at 3:37 PM, Anna Zaks <ganna at