From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79187 invoked by alias); 9 Aug 2017 16:22:00 -0000 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 Received: (qmail 79156 invoked by uid 89); 9 Aug 2017 16:21:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2270 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Aug 2017 16:21:58 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 30647F8BA9; Wed, 9 Aug 2017 16:21:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 30647F8BA9 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-116-95.phx2.redhat.com [10.3.116.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id CF9125C8B0; Wed, 9 Aug 2017 16:21:44 +0000 (UTC) Subject: Re: [PATCH] Forbid section anchors for ASan build (PR sanitizer/81697) To: Vyacheslav Barinov , Andrew Pinski Cc: GCC Patches , alexey.merzlyakov@samsung.com References: <20170808061543.13774-1-v.barinov@samsung.com> <878tiu5zfh.fsf@samsung.com> From: Jeff Law Message-ID: Date: Wed, 09 Aug 2017 16:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <878tiu5zfh.fsf@samsung.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00679.txt.bz2 On 08/08/2017 12:46 AM, Vyacheslav Barinov wrote: > Hello, > > Andrew Pinski writes: > >> On Mon, Aug 7, 2017 at 11:15 PM, Slava Barinov wrote: >>> gcc/ >>> * varasm.c (use_object_blocks_p): Forbid section anchors for ASan >>> >>> gcc/testsuite/ >>> * g++.dg/asan/global-alignment.cc: New test to test global >>> variables alignment. >> >> >> Can you describe this a little bit more? What is going wrong here? >> Is it because there is no red zone between the variables? > I've described situation in bugzilla PR 81697 with compiled files dumps, but > briefly yes, red zone size is incorrect between global variables. > > On certain platforms (we checked at least arm and ppc) the flow is following: > make_decl_rtl() calls create_block_symbol() on decl tree with ASan global > variable describing a string. But then get_variable_section() returns wrong > section (.rodata.str1.4 in my case) because check in asan_protect_global() > returns false due to !DECL_RTL_SET_P check. > > When variable is placed not into .rodata, but into .rodata.str ld treats it as > string and just shrinks the large part of red zone silently (gold at least > prints warning about wrong string alignment). But in run time libasan expects > that red zone is still there and reports false positives. > > In order to prevent the setting of RTL before ASan handling I tried to > reproduce the x86_64 behavior and found that use_object_blocks_p() returns > false for that platform. Accordingly to the function comment it reports if > 'current compilation mode benefits from grouping', and just switching it off > for any ASan builds resolves the issue. > >> Also I noticed you are using .cc as the testcase file name, why don't >> you use .C instead and then you won't need the other patch which you >> just posted. > Okay, attaching rebased version. In many ways it'd be better if asan could be made to work with section anchors. Doing so means the code we're running for asan more closely matches what we're running in the normal case. But I'll defer to Jakub and Marek as they know the sanitizers far better than I do and are more familiar with the expected tradeoffs. jeff