From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2169 invoked by alias); 4 Sep 2017 08:37:49 -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 2157 invoked by uid 89); 4 Sep 2017 08:37:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=U*pinskia, sk:pinskia, Maxim, maxim X-HELO: mailout2.w1.samsung.com Received: from mailout2.w1.samsung.com (HELO mailout2.w1.samsung.com) (210.118.77.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Sep 2017 08:37:46 +0000 Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20170904083742euoutp022b465671b9a61ce27be4f49107dd5d30~hG8AOFfDw0667306673euoutp02a; Mon, 4 Sep 2017 08:37:42 +0000 (GMT) Received: from eusmges2.samsung.com (unknown [203.254.199.241]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20170904083741eucas1p137033d500759cc9b2eaeeb74923ec0d9~hG7-m6E7z2425724257eucas1p1o; Mon, 4 Sep 2017 08:37:41 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges2.samsung.com (EUCPMTA) with SMTP id A7.51.12907.5D01DA95; Mon, 4 Sep 2017 09:37:41 +0100 (BST) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20170904083740eucas1p1e4cedbe6f5c5b93d29200fee9727b543~hG7-BUEk52251522515eucas1p1r; Mon, 4 Sep 2017 08:37:40 +0000 (GMT) Received: from eusync3.samsung.com ( [203.254.199.213]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id BD.18.20118.4D01DA95; Mon, 4 Sep 2017 09:37:40 +0100 (BST) Received: from [106.109.129.18] by eusync3.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0OVQ001IRYMQ5090@eusync3.samsung.com>; Mon, 04 Sep 2017 09:37:40 +0100 (BST) Subject: Re: [PATCH] Forbid section anchors for ASan build (PR sanitizer/81697) To: Jeff Law , Vyacheslav Barinov , Andrew Pinski , Jakub Jelinek Cc: GCC Patches , alexey.merzlyakov@samsung.com From: Maxim Ostapenko Message-id: <59AD10D2.8000904@samsung.com> Date: Mon, 04 Sep 2017 08:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset="utf-8"; format="flowed" Content-transfer-encoding: 7bit X-CMS-MailID: 20170904083740eucas1p1e4cedbe6f5c5b93d29200fee9727b543 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?TWFrc2ltIE9zdGFwZW5rbxtTUlItU1cgVG9vbHMgTGFiGw==?= =?UTF-8?B?7IK87ISx7KCE7J6QG0VuZ2luZWVy?= X-Global-Sender: =?UTF-8?B?TWF4aW0gT3N0YXBlbmtvG1NSUi1TVyBUb29scyBMYWIbU2Ft?= =?UTF-8?B?c3VuZ8KgRWxlY3Ryb25pY3MbRW5naW5lZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG0NJU0hRG0MxMEdEMDFHRDAxMDE1Nw==?= CMS-TYPE: 201P X-CMS-RootMailID: 20170808061550eucas1p2c68f4339a161e764b8ec3cd7f310b5e0 X-RootMTR: 20170808061550eucas1p2c68f4339a161e764b8ec3cd7f310b5e0 References: <20170808061543.13774-1-v.barinov@samsung.com> <878tiu5zfh.fsf@samsung.com> X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00147.txt.bz2 + Jakub On 09/08/17 19:21, Jeff Law wrote: > 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. I'm not very familiar with this code, but as far as I can understand, the problem is that we have a circular dependency here -- categorize_decl_for_section calls asan_protect_global that returns false because DECL_RTL is not set at this point and assigns decl to SECCAT_RODATA_MERGE_CONST section. But when make_decl_rtl sets up SET_DECL_RTL (decl, x) and following asan_protect_global calls will return true and we end up with mismatch between section and alignment requirements. Perhaps we can add an additional flag to asan_protect_global to change its behavior in such cases (e.g. don't account for DECL_RTL_SET_P)? In this case we will change the section for SECCAT_RODATA without affecting global section anchors flag. -Maxim > > 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 > > >