From patchwork Wed Dec 5 11:35:21 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 203856 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id AD0EA2C009A for ; Wed, 5 Dec 2012 22:35:37 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1355312138; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=dg0QljONskGPG8Ptz4Ju W2OMoVI=; b=Lx0ahhPTqRBtMygvTjQ0LZkge4+3q7gyCgveqRrf6SrBtWbC/pFP VhL21bVuqBF34H2kNxsgXvcuKylSWof92c/itUcsUJ1zoJNK91Al+KMT052Yx+DL w4nFoSlf8BG28m0izg3w4i+DxzkL4zmCcKR9gmkxeaHHsE/PKkm5uqw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=TojP4e9AWX4kN9YS3LP7xsyw5281Qb9oZqMk8lbopMSgi0TyyTBvQayQDoTBRM kwOZEe+PoI00ADcUod+gmZr/yMTkAu4uPhxkt4OfW2L5C+DdRfIZj+OdyXUVqxnH knXmTyr4hgRBIR5o7KpiQAFR9/WvI5X9qZqeA0IvT3XRc=; Received: (qmail 17523 invoked by alias); 5 Dec 2012 11:35:34 -0000 Received: (qmail 17423 invoked by uid 22791); 5 Dec 2012 11:35:33 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Dec 2012 11:35:24 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB5BZOne032131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Dec 2012 06:35:24 -0500 Received: from zalov.redhat.com (vpn1-5-46.ams2.redhat.com [10.36.5.46]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qB5BZMI9007536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2012 06:35:23 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qB5BZL3j013018; Wed, 5 Dec 2012 12:35:21 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qB5BZLgp013017; Wed, 5 Dec 2012 12:35:21 +0100 Date: Wed, 5 Dec 2012 12:35:21 +0100 From: Jakub Jelinek To: Dodji Seketeli , Konstantin Serebryany Cc: gcc-patches@gcc.gnu.org Subject: [asan] Instrument non-public common vars Message-ID: <20121205113521.GM2315@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! The c-c++-common/asan/global-overflow-1.c test fails because we don't instrument local common vars (those that go into .lcomm). Of course we can't instrument them if they are emitted using .lcomm, because the linker can arbitrarily reorder the .lcomm vars for best packing, but we can instrument them by forcing them into .bss instead. Public common variables obviously still can't be instrumented, because they have to be emitted as .comm, users can rely on common var merging, provide non-zero definition somewhere else, etc. The following patch implements that, ok for trunk? 2012-12-05 Jakub Jelinek * varasm.c (get_variable_section): Don't return lcomm_section for asan_protect_global decls. * asan.c (asan_protect_global): Only avoid public common variables. Don't call get_variable_section here. Jakub --- gcc/varasm.c.jj 2012-12-03 12:41:32.000000000 +0100 +++ gcc/varasm.c 2012-12-05 08:24:59.728816975 +0100 @@ -1034,7 +1034,8 @@ get_variable_section (tree decl, bool pr && !(prefer_noswitch_p && targetm.have_switchable_bss_sections) && bss_initializer_p (decl)) { - if (!TREE_PUBLIC (decl)) + if (!TREE_PUBLIC (decl) + && !(flag_asan && asan_protect_global (decl))) return lcomm_section; if (bss_noswitch_section) return bss_noswitch_section; --- gcc/asan.c.jj 2012-12-04 14:19:36.000000000 +0100 +++ gcc/asan.c 2012-12-05 08:25:50.417507197 +0100 @@ -428,7 +428,6 @@ bool asan_protect_global (tree decl) { rtx rtl, symbol; - section *sect; if (TREE_CODE (decl) != VAR_DECL /* TLS vars aren't statically protectable. */ @@ -442,7 +441,7 @@ asan_protect_global (tree decl) padding or not. */ || DECL_ONE_ONLY (decl) /* Similarly for common vars. People can use -fno-common. */ - || DECL_COMMON (decl) + || (DECL_COMMON (decl) && TREE_PUBLIC (decl)) /* Don't protect if using user section, often vars placed into user section from multiple TUs are then assumed to be an array of such vars, putting padding in there @@ -464,10 +463,6 @@ asan_protect_global (tree decl) || TREE_CONSTANT_POOL_ADDRESS_P (symbol)) return false; - sect = get_variable_section (decl, false); - if (sect->common.flags & SECTION_COMMON) - return false; - if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))) return false;