similar to: [LLVMdev] [RFC] Parsing runtime flags in sanitizers (ASan/LSan/UBSan)

On Mon, Dec 8, 2014 at 2:00 AM, Alexander Potapenko <glider at google.com> wrote: > Hope you're assuming there's always a single copy of common_flags in > the process. > This isn't the case for e.g. ASan+UBSan on Mac, but that's a broken setup. > > What if we let the tools protect specific flags (by adding a bool to > each flag) once they set their values

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc

Hi, Currently the first stage ("run sanitizer tests in gcc build") of the sanitizer-ppc64-linux1 buildbot is only failing because of: + cd clang_build + make -j16 check-lsan make: *** No rule to make target `check-lsan'. Stop. + echo @@@STEP_FAILURE@@@ @@@STEP_FAILURE@@@ + cd clang_build + make -j16 check-msan make: *** No rule to make target `check-msan'. Stop. + echo

X32 support patch for compiler-rt. Applies against current trunk. --- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21 06:27:38.000000000 +0000 +++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21 11:16:55.891621025 +0000 @@ -41,7 +41,18 @@ SupportedArches += x86_64 endif else - SupportedArches := x86_64 + # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit

Hello, I have several low priority UBSan questions... (1) Is there a way for UBSan to print its output to a file that the user specified (e.g. via option) instead of dumping everything on stderr? (2) Out of curiosity, why is the name of the option for printing the stacktrace spelled "UBSAN_OPTIONS=print_stacktrace=1", though the allowed value is 1? Since the only one value is

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

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

> 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

Hi, We are trying to enable LeakSanitizer on our asan/msan llvm bootstrap bot (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/). In clang itself there are two leaks (http://llvm.org/bugs/show_bug.cgi?id=18318, http://llvm-reviews.chandlerc.com/D2472) and one lsan-hostile feature (http://llvm.org/bugs/show_bug.cgi?id=18320), all of which are easy to fix. And there are also

UBsan tests work for me when I run "check-ubsan" in both build trees (the one with gcc 4.6.3 as a host compiler, and the one with fresh Clang). It's pretty convenient for us to use fresh Clang to configure LLVM and compiler-rt. One major reason is that autoconf/make build system always builds compiler-rt with just-built Clang. There are other benefits, like keeping sanitizers code

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

Folks, As of this run: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/746 There are three classes of failures that need fixing before we get the bot green: 1. AddressSanitizer.BuiltinLongJmpTest Unit Test Two configurations fail: * Asan-arm-inline-Test * Asan-arm-with-calls-Test I wonder what's the best way to run it individually and reduce the error. I'm not

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

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 there is some platform-specific code in all the sanitizers, and many of them heavily depend on the address

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

Hi, I'm currently trying to find and fix memory leaks (compiling with ``-fsanitize=address``) in the KLEE tool [1] an having found some leaks and I'm having trouble suppressing them. I'm trying to suppress them using the ``-fsanitize-blacklist=blacklist.txt`` option as documented at [2]. I'm using Clang 3.7 ( Arch Linux package 3.7.0-6). The sort of reported leaks I see are ```

> Android runtime is special, we build it in a separate build tree configured with > -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake This worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory.

On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> wrote: > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > failing tests I see are in ubsan: > > Failing Tests (6): > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp > UndefinedBehaviorSanitizer ::

On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> > wrote: > > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > > failing tests I see are in ubsan: > > > > Failing Tests (6): > > UndefinedBehaviorSanitizer ::