From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67146 invoked by alias); 17 Apr 2019 15:14:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 67133 invoked by uid 89); 17 Apr 2019 15:14:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=1024*1024, !tree_readonly, H*Ad:U*aph, DECL_COMMON X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Apr 2019 15:14:17 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1hGmGM-0006Bl-G6 from joseph_myers@mentor.com ; Wed, 17 Apr 2019 08:14:14 -0700 Received: from digraph.polyomino.org.uk (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 17 Apr 2019 16:14:11 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1hGmGI-0000XW-Hu; Wed, 17 Apr 2019 15:14:10 +0000 Date: Wed, 17 Apr 2019 15:14:00 -0000 From: Joseph Myers To: Richard Biener CC: Andrew Haley , Thomas Koenig , gcc mailing list , "fortran@gcc.gnu.org" Subject: Re: Putting an all-zero variable into BSS In-Reply-To: Message-ID: References: <87ef6koy6f.fsf@igel.home> <3930c1e6-fa7c-746b-c21a-8e8fa457deec@netcologne.de> <871s2ihkfs.fsf@igel.home> <361F609E-2767-4AF6-BD0C-E41F4666AAF2@gmail.com> <441499d5-9b84-2d5e-e152-654f4014c0f4@netcologne.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2019-04/txt/msg00190.txt.bz2 On Mon, 8 Apr 2019, Richard Biener wrote: > That is, the C testcase > > const char x[1024*1024] = {}; > > reproduces the "issue". The comment in bss_initializer_p though > explicitely says > > /* Do not put non-common constants into the .bss section, they belong in > a readonly section, except when NAMED is true. */ > return ((!TREE_READONLY (decl) || DECL_COMMON (decl) || named) > > (where named refers to explicit .bss section marked decls). Note > the docs for -fzero-initialized-in-bss doesn't mention that this doesn't > apply for readonly variables. I'd say it's a security risk (breaks expected hardening properties) for a const variable with static storage duration not to end up in read-only memory, regardless of its size or contents, so such variables should not be put in BSS by default. -- Joseph S. Myers joseph@codesourcery.com