From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14477 invoked by alias); 30 Nov 2012 09:33:21 -0000 Received: (qmail 14425 invoked by uid 22791); 30 Nov 2012 09:33:19 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_KC,TW_LV X-Spam-Check-By: sourceware.org Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Nov 2012 09:33:14 +0000 Received: by mail-la0-f47.google.com with SMTP id u2so187842lag.20 for ; Fri, 30 Nov 2012 01:33:12 -0800 (PST) Received: by 10.112.14.107 with SMTP id o11mr566042lbc.98.1354267992533; Fri, 30 Nov 2012 01:33:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.135.105 with HTTP; Fri, 30 Nov 2012 01:32:52 -0800 (PST) In-Reply-To: <20121129204636.GC2315@tucnak.redhat.com> References: <20121128102445.GH2315@tucnak.redhat.com> <20121128110327.GI2315@tucnak.redhat.com> <20121129204636.GC2315@tucnak.redhat.com> From: Konstantin Serebryany Date: Fri, 30 Nov 2012 09:35:00 -0000 Message-ID: Subject: Re: [PATCH] asan_test.cc from llvm To: Jakub Jelinek Cc: Wei Mi , GCC Patches , David Li , Diego Novillo , Kostya Serebryany , Dodji Seketeli Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg02523.txt.bz2 Jakub, Great result! Ideally, I would like to limit the differences from upstream. I'll put some of your changes upstream, for others I'd ask you to consider other choices. -#include "gtest/gtest.h" +#include "dejagnu-gtest.h" Maybe like this? #if ASAN_USE_DEJAGNU_GTEST #include "dejagnu-gtest.h" #else #include "gtest/gtest.h" #endif Can we have gcc_asan_test.C which will #include the unchanged (modulo the comment header) asan_test.cc and have dejagnu lines there? Like this: // { dg-do run { target { mmap && pthread } } } ... #include asan_test.cc +#elif defined(__SANITIZE_ADDRESS__) + bool asan = 1; I'll put this upstream. +#ifdef __SANITIZE_ADDRESS__ + // Avoid this test during dejagnu testing, it is too expensive + if (getenv ("GCC_TEST_RUN_EXPENSIVE") == NULL) + return; +#endif I'd prefer to simply put this w/o ifdef. -# error "please define ASAN_HAS_BLACKLIST" +//# error "please define ASAN_HAS_BLACKLIST" You can add -DASAN_HAS_BLACKLIST=0 to the command line. If/when gcc gets blacklist support, we'll redefine it to 1 +#if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__) this is upstreamable +#ifdef __GNUC__ +# define break_optimization(arg) __asm__ __volatile__ ("" : : "r" (arg) : "memory") +#endif + That's a nice piece of magic, let me use this too. Cool! --kcc On Fri, Nov 30, 2012 at 12:46 AM, Jakub Jelinek wrote: > Hi! > > On Wed, Nov 28, 2012 at 03:13:14PM +0400, Konstantin Serebryany wrote: >> That's a bit scary (and will be slower than with gtest). >> But if we can limit the changes by replacing >> asan/tests/asan_test_config.h (and maybe some minimal other changes) >> that may work. > > So, here is a rough port of asan_test.cc (haven't added the few smaller > other tests yet until this one is resolved). > > I'm attaching both gcc patch and diff between the current llvm files > and the files added in the patch to make it clear what changes were done. > Primarily it is replacing the gtest/gtest.h include with new dejagnu-gtest.h > header that contains needed macros, adding some tcl stuff around it and > a few dejagnu lines at the beginning. > > I've disabled the ManyThreads test, because it seems to be almost completely > library bound and was very slow (order of minutes), many people run make > check for gcc with very high -jN factors and having some test spawn 1000 > threads and in each allocate lots of memory is undersirable for normal > testing. > > Attaching also make check-g++ RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp' > result, there are some failures that need analysis (some of it might be > because of the missing __asan_handle_no_return instrumentation from GCC, > waiting there for review of the prerequisite patch, another thing is > instrumentation of bitfields). > But for -m32/-m64 together that is still: > > # of expected passes 2301 > # of unexpected failures 61 > # of unsupported tests 18 > > so not that bad. Both -m32 and -m64 testing together took around 90 seconds > (without the ManyThreads tests, with it (GCC_TEST_RUN_EXPENSIVE=1 in > environment) more than 4 minutes). > > Jakub