From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2749 invoked by alias); 12 Oct 2012 16:30:44 -0000 Received: (qmail 2739 invoked by uid 22791); 12 Oct 2012 16:30:40 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_CP,TW_LV X-Spam-Check-By: sourceware.org Received: from mail-lb0-f175.google.com (HELO mail-lb0-f175.google.com) (209.85.217.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Oct 2012 16:30:35 +0000 Received: by mail-lb0-f175.google.com with SMTP id y2so2220802lbk.20 for ; Fri, 12 Oct 2012 09:30:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=GSOe3gO7WVseL4Feu9RMOfgHFzy56V963wS5mkaH6tc=; b=jYbUen49ZPFbes/foqU6eqcEKft3p4uSLa0Idd+gq9HKqVRmL+JZEtGqVCxIDUyZGC xZqs09pcERog8E5mJtJHR5XZ0LoNqQl14/31zNIqjzCsu6OfdfSX036uBoYNo+Qm1ogg /Fow5pPGm66ABYs2FEmrSXjisczar9uEUZOWpW1fq1jT4NbgLh8UQrG7R1+ptUKHBSeq pzp6yshwRNyZJ1IEy7Wv252UlxnGbwvWIzjNylKF5i44K2UTDhzyVJOvUSdPeU2mYHLX +BgSJSyF0feQt3wMcRCanROqUDf/BKO87WVdWxPPsubDNIZJtIVuwlgMYEX2u6ZRW8xQ e+wA== MIME-Version: 1.0 Received: by 10.152.47.148 with SMTP id d20mr4352872lan.42.1350059433764; Fri, 12 Oct 2012 09:30:33 -0700 (PDT) Received: by 10.152.132.136 with HTTP; Fri, 12 Oct 2012 09:30:33 -0700 (PDT) In-Reply-To: <20121012071557.GI584@tucnak.redhat.com> References: <20121011163847.GE584@tucnak.redhat.com> <5076FE77.1060806@google.com> <20121011173129.GF584@tucnak.redhat.com> <20121012071557.GI584@tucnak.redhat.com> Date: Fri, 12 Oct 2012 16:33:00 -0000 Message-ID: Subject: Re: [asan] Emit GIMPLE directly, small cleanups From: Xinliang David Li To: Jakub Jelinek Cc: Wei Mi , Diego Novillo , Dodji Seketeli , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlEJXYN4L1A5dQ0anqsoUeJH8F+S6/W0i6thLWGfLtawDtzMLl5ZEAgkugvHPe45xP+ePec+CVHvyK1IeQT0keeHZpmlzXMDMFXG26l2MZDaDNrYsKRGGQmGjIJSJP2TneqeSVNUnVzHgPAK26EFAz946FllstPa38K3xr0IUwXGUm3tVjegE9jTWxm3IwQUR4OJOws 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-10/txt/msg01237.txt.bz2 On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek wrote: > On Thu, Oct 11, 2012 at 04:19:18PM -0700, Wei Mi wrote: >> Here is the initial test results of gcc asan patch, and it shows us >> some missing features in gcc but existing in llvm. >> [1]. gcc regression test for gcc-asan passes. >> [2]. llvm regression tests for gcc-asan: 18 failures in 123 for tests >> written in google test and 24 failures in 28 for tests written in lit >> tests. >> >> gcc missing features: > > I think LLVM calls the option -faddress-sanitizer, perhaps we should rename > -fasan to that too for some compatibility. For the varios knobs LLVM asan > has we could add params to params.def if we want to support them. > >> 1. gcc implementation doesn't support stack/global overflow check > > Yeah, I think the stack check shouldn't be that hard and can hack it up, > I'll perhaps leave the global vars stuff to Dodji or others if he has time. Since the stack part is relative self contained, might it be better for Wei (he is new) to tackle it with guidance from you? Global handling needs people more experienced with varasm stuff. > >> 1. gcc implementation doesn't support some attributes, such as >> __attribute__((no_address_safety_analysis)), which llvm does > > Yeah, shouldn't be hard. > yes -- that is simple. >> 2. gcc doesn't detect out-of-bound bitfield access of heap, which llvm does > > Testcase (for everything testcases would be useful, and of course the > runtime library too)? Yeah, the code currently punts on those, the question > is how to handle them. The code should sythensize the smallest containing byte/word/doubleword/qword of the bitfield and then compute the shadow address. > >> 3. gcc doesn't detect out-of-bound memset, memcopy, strcat and strcpy >> for heap allocated memory or string, which llvm does > > That is easy (we can easily handle instrumenting lots of builtins). > Just a big switch on DECL_FUNCTION_CODE, collecting src/dst addresses and > length for each of them and adding the instrumentation for first and last > bytes in the strings. Yes. > >> 4. gcc doesn't contain similar options: -mllvm -asan-blacklist, -mllvm >> -asan-initialization-order > > I must say I don't like the -asan-blacklist option at all, IMHO it is much > saner to just ask users to use attributes (or pragmas around whole headers). But the option is easy to have too. > >> 5. gcc -fasan doesn't take effect at -O0, but llvm does. Most lit >> tests contain checks from -O0 to -O3, which makes gcc fail. > > That is because of the place where the instrumentation is scheduled right > now in the pass queue. We can easily add a pass_asan_O0 that will run say > close to pass_lower_complex_O0. Right. thanks, David > > Jakub