From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 4FA7E3858D37 for ; Fri, 5 Aug 2022 08:30:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4FA7E3858D37 Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2757wuwB016039; Fri, 5 Aug 2022 08:30:19 GMT Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3hmvh9xt15-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Aug 2022 08:30:19 +0000 Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 2758AnwE010928; Fri, 5 Aug 2022 08:30:18 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2109.outbound.protection.outlook.com [104.47.70.109]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3hmu353ff1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Aug 2022 08:30:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jx8SLOFfvF1tBUSrfAdCmdrjYdpGIq5n3g3tkirT+rlVEflFVQzYUS4t8c7Ms0doGOQksUZvEG+mzpS5lnXeGj5o73VNn5UMKaBzk5SQ1LuYbk00Fcp7bNOhnjlXPwcEqNor0Tjc5QP6fPxwYi2+tyMJaqRnkV2bYCMQ4VljRHOwqwId7y64XRDmaOuZ7BHrsGf0lb+c1m+enWb/YXUxXQWokc4ViD2yPXqaA4nfvYnGXMiGlTFZl6j5ASC3HcvHHpmrSADghNLVNiGHhPC59dmFxwMCvB6M2tffD6172F7Rl/DwIy2cjueE2RuTtFvOER5iJZDotPb/3Uch9YszRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JSOGmQ8M8C1hCXXhNR1ouJS/L0JfN+sgAH3QMecAkrE=; b=VZjbPs3SLQWapsujtNtzDttPcHfVZdh7T2OBxPNNC6Zj+BRJRCG+CLbj5rKYSTgGz7jklAWfLYAl4hVe8XDcbvIz23jOgvfpvZehnZJhqBAphIddr1h28iDXzqwxsvLaSiIKOSFVQlaOKiXJIiCZPHegJKcXJKsy/GrPPfBKwbBSQFQXdb4DazzPTpEx2rarSWF5KLjoH7FFRR/fLtTltC5KGAGG1ehlaIuDDm5BiWqxYKjzHCCYRMgNE5RwZgghEhrs/93xNcDHuqHLurlNa9LbNSOfDcxbBPECWYWL7FVigeKTUT7IOY0CJodVXZsQe+7poUhIMXmUDZB70bCEwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) by MWHPR1001MB2413.namprd10.prod.outlook.com (2603:10b6:301:31::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.15; Fri, 5 Aug 2022 08:30:13 +0000 Received: from BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::b5ee:262a:b151:2fdd]) by BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::b5ee:262a:b151:2fdd%4]) with mapi id 15.20.5504.014; Fri, 5 Aug 2022 08:30:13 +0000 From: "Jose E. Marchesi" To: Richard Biener Cc: GCC Patches Subject: Re: [PATCH] place `const volatile' objects in read-only sections References: <87sfmbxyyj.fsf@oracle.com> Date: Fri, 05 Aug 2022 10:26:25 +0200 In-Reply-To: (Richard Biener's message of "Fri, 5 Aug 2022 08:52:33 +0200") Message-ID: <87h72rumdq.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: LO2P265CA0074.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::14) To BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f624e930-7cb2-4a71-02ca-08da76bcb7b7 X-MS-TrafficTypeDiagnostic: MWHPR1001MB2413:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: daLMQtJSGVsUnOMi6zpgMDtGoJcoKoOBXhehXu4R2udwVSi2J86/x6/n6Uk3KrRFDA+YZVDduby0PBIQTJ32exoCZIsVh90aQ6YCtHumOJhbN0Vfakhr6yuXx32rQKJxkahJ5qDnxfp4esDEj78i8e5SO0HNEzKrqu9/2t62UE9+khxtiP6EwDoFGh//ynI4vzqGplr4RbOhssNN9AB8kl1tV6i8rvXZtCXXJQKKVJpwZSFqT02gA6nty8SzL5UnVzSuLht0uELnR5241ouD60GJr1J18qmvS2Rg+xsb4BkGg/u09nzTkY3RbCxfbvg4kxkJNC7tx7PSCz/LL3HDGFL5n0PfkFAY6nGiWL1TmKM3ytUJ4nE5HpG1P10Is+FUMomLNe/lgQyTYQe8XcH3+hi3QPNeGJiSnCyFhPYJrCfHpZdAgD4LHGV32ZK8fz/tocGuDP/kbaKzDqv6/Xc8JGE56aVgaL48mS5AOpIr1eu897SooMCEMskzUex2dpr1nmjfjOxXMtYboOGqDqse9fvyu1UMGpHiSUUPpBeNfIrhiLFMF5+ge1UHVpMYRCHz8EZFcsO8NQfVLqe9HmdAWxRqfdSfLy0iI7WASJ8+p0F02RJ4Bsf53ma4lU3D7Gv8BP2BTqWfCotfddNJq7bXd2HQl37cuVIkNQ/GYXL8HUynAyHbqkYJULi3WuXeRXe5YkeCAWzttwZq+b1YlMWYSOTv5930g00OzdmvSdL6UXLA9ApQqEtxQGAK6/UiAxPBv61nmZ0OxjzqQyampANk9FsUSt8gI3HtoxEP4l+g0OAuBAqT1vKDIbLiR5F/vbUl93LLllgdz6/zoDbOeNr9NSzi6VZ35F/fFnJnTBeGfhWBvmYTKCrD8YFYq9BtoHSeDaLHDrI1yD5akrQLrSVGTg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR10MB2888.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(366004)(39860400002)(136003)(376002)(346002)(396003)(52116002)(41300700001)(6666004)(26005)(6512007)(86362001)(6506007)(38350700002)(38100700002)(53546011)(2616005)(36756003)(66946007)(83380400001)(186003)(66556008)(66476007)(4326008)(478600001)(8936002)(2906002)(5660300002)(6486002)(966005)(8676002)(316002)(6916009)(81973001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?XAu86h2sMj/VJaui5/96cMM37u4/oulehP7oIjk3j+w9DrnvOeIvHM6Hzy9p?= =?us-ascii?Q?xubHIkWo0FDQkcZYQTZmBexGtyrZ0oFUFiabU/RwiK0IOzN5t+CxJVZrcTva?= =?us-ascii?Q?EPl4D18sbm+mVCL6/q660acSnkWf7KMP2Ir5L98FHz2OoziTxXz1beyRBzyB?= =?us-ascii?Q?WXX3P5A5Hk3KSdlVHzdG6qNlUup6CRTKnRIFm8aBwbOdGtqEkTfZj5hQhs2X?= =?us-ascii?Q?KMTj1XOL+15tHUwCZkyy6DuQ+0vW+WaJXKEsQIiyRWBw1RzLx92BkeU5h8Tv?= =?us-ascii?Q?3UH9moHYKvl3KL/iCpeQ2iXK39YKfIlJaoqRecWAA9EjHNx4EywotfoIMicf?= =?us-ascii?Q?oBd5RyT3M8GDWm1jWmQhkD5yOZbvf4QYqVSprTgMqwGI1GXCZrsTzE7CRSaZ?= =?us-ascii?Q?0HH/1rRy24xc9uh6hYfhK03kXghUJyiyMDCm0EsYaBY2Ab2024hY7JiKDT4Z?= =?us-ascii?Q?BbESclYU4ayh1fbBPfqUtlpokbrCcbp+viqT0V2oBfo3lNlPxMF8fVypmsSi?= =?us-ascii?Q?ex4oMGhcekCP2qhbpwSleKx8QAfTjmGKFbikk4kksK85RKNDGzH+bI/H3rvV?= =?us-ascii?Q?GUpcHmH+1gr2s9FGn51nMSnhXxxQaJ1e8t2uQzNz8ZRTNUcl+kP4/qdJHv4b?= =?us-ascii?Q?oQp/HINBB6qn2DZF46V0cmyhJprX1Ap6k2+6HPWGBjjVFo1LYtSWRmy3UWtJ?= =?us-ascii?Q?/O1Yog9sGCnqHWVDs/Vax5VLPdjwKiV0uej3KJtijiYnbw/eW6S8CevMzUCL?= =?us-ascii?Q?7D3GYhw6iKQO8UX+qcP5TB7O2J8wnAA3DxV0pTNjp9YHhIoo6+ibt0b3z4nu?= =?us-ascii?Q?m4WwDApdM/2B0r5yiigT9oXnINDf9h6CdoGjAVGxzX4+Tun96vQsgMQJlXdS?= =?us-ascii?Q?3S48mL7/D2SINCUK/dQ/J50Pd2Nbnea8nFIEgWH5EhQ+adVfL6GrTcP4Kc3t?= =?us-ascii?Q?iXno2+8NIqA3wf812qKYub9g8uLTffL7VWKBMYy3bu73u28PU3F0dtFjGT65?= =?us-ascii?Q?+ydxLGhGGmu4zQxcup0wGHyI3RC5ipakyfsSNo6d+bqGBk2sFD7HyUnupYC7?= =?us-ascii?Q?rJxps/QoURtNDa+M54MnV+XZvMQ/hRERfU5AsYh8UAXH0VQg4EvMgdML6xCz?= =?us-ascii?Q?9/dD8He/gxZuR64QGSayQ6Qqy4snqQ4HgUGWtmceIUrlgsUYJ1xy/choR6yB?= =?us-ascii?Q?bQ4oBV9SfrSTnx3C0hGelpEd/hmHiA/zGNl/Kt6dhnoQc9U/0QGq1/mygW/e?= =?us-ascii?Q?Lp5VbZiuaY33IXrJLcpxY1QB0TNdhOCYCMLPZTKqzVXpJO96mMCz5p9XzpcP?= =?us-ascii?Q?Ecpj5Q1RuE8rvECiwRKS1S0nQaFrfxQFn8/993Azf+oBpgPD9/H1LLZsaGH2?= =?us-ascii?Q?8YeI1dIWrcqEIa9hpms21jIzYrB1gh1xVapkUJzNqGG3msBmPZMNytiUopWz?= =?us-ascii?Q?t5HIZIR7vb9owAutTYgf9MNVjTm2KQnN8QNWYrwC/1+gvNNh/gm23HaebGmE?= =?us-ascii?Q?h44oqE7ExJmGezyb5QtgiKBBQYdvudGVvF7BUKnhHPykKTIFurCIr+ri64KS?= =?us-ascii?Q?B+hEet6RrlBC58wpvEn7A3IWkW4kNo9S+5XwJg5on78gA5Mjq4mFUhkcONll?= =?us-ascii?Q?Ug=3D=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: f624e930-7cb2-4a71-02ca-08da76bcb7b7 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2022 08:30:13.6062 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mHrMuWOgPRxD2YHmC20EvCZ2eZ9i06wgT3ByLG5pj10Nrt83pdsBw1/jPOYP08HDppeRQ3nUS2jsBqfxoCGgJVkq/w1ii4O191aikyyWIAo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1001MB2413 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-05_03,2022-08-04_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 spamscore=0 phishscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208050041 X-Proofpoint-ORIG-GUID: YPXpZhHIYM5DdiQaFzm8GF3fPwRHCcyG X-Proofpoint-GUID: YPXpZhHIYM5DdiQaFzm8GF3fPwRHCcyG X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2022 08:30:25 -0000 Hi Richard. > On Fri, Aug 5, 2022 at 3:27 AM Jose E. Marchesi via Gcc-patches > wrote: >> >> >> Hi people! >> >> First of all, a bit of context. >> >> It is common for C BPF programs to use variables that are implicitly set >> by the underlying BPF machinery and not by the program itself. It is >> also necessary for these variables to be stored in read-only storage so >> the BPF verifier recognizes them as such. This leads to declarations >> using both `const' and `volatile' qualifiers, like this: >> >> const volatile unsigned char is_allow_list = 0; >> >> Where `volatile' is used to avoid the compiler to optimize out the >> variable, or turn it into a constant, and `const' to make sure it is >> placed in .rodata. >> >> Now, it happens that: >> >> - GCC places `const volatile' objects in the .data section, under the >> assumption that `volatile' somehow voids the `const'. >> >> - LLVM places `const volatile' objects in .rodata, under the >> assumption that `volatile' is orthogonal to `const'. >> >> So there is a divergence, and this divergence has practical >> consequences: it makes BPF programs compiled with GCC to not work >> properly. >> >> When looking into this, I found this bugzilla: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521 >> "change semantics of const volatile variables" >> >> which was filed back in 2005. This report was already asking to put >> `const volatile' objects in .rodata, questioning the current behavior. >> >> While discussing this in the #gcc IRC channel I was pointed out to the >> following excerpt from the C18 spec: >> >> 6.7.3 Type qualifiers / 5 The properties associated with qualified >> types are meaningful only for expressions that are >> lval-values [note 135] >> >> >> 135) The implementation may place a const object that is not >> volatile in a read-only region of storage. Moreover, the >> implementation need not allocate storage for such an object if >> its $ address is never used. >> >> This footnote may be interpreted as if const objects that are volatile >> shouldn't be put in read-only storage. Even if I was not very convinced >> of that interpretation (see my earlier comment in BZ 25521) I filed the >> following issue in the LLVM tracker in order to discuss the matter: >> >> https://github.com/llvm/llvm-project/issues/56468 >> >> As you can see, Aaron Ballman, one of the LLVM hackers, asked the WG14 >> reflectors about this. He reported back that the reflectors consider >> footnote 135 has not normative value. >> >> So, not having a normative mandate on either direction, there are two >> options: >> >> a) To change GCC to place `const volatile' objects in .rodata instead >> of .data. >> >> b) To change LLVM to place `const volatile' objects in .data instead >> of .rodata. >> >> Considering that: >> >> - One target (bpf-unknown-none) breaks with the current GCC behavior. >> >> - No target/platform relies on the GCC behavior, that we know. (And it >> is unlikely there is any, at least for targets also supported by >> LLVM.) >> >> - Changing the LLVM behavior at this point would be very severely >> traumatic for the BPF people and their users. >> >> I think the right thing to do is a). >> Therefore this patch. >> >> A note about the patch itself: >> >> I am not that familiar with the middle-end and in this patch I am >> assuming that a `var|constructor + SIDE_EFFECTS' is the result of >> `volatile' (or an equivalent language construction) and nothing else. >> It would be good if some middle-end wizard could confirm this. > > Yes, for decls that sounds correct. For a CTOR it just means > re-evaluation is not safe. Thanks for confirming. >> Regtested in x86_64-linux-gnu and bpf-unknown-none. >> No regressions observed. > > I think this warrants a testcase. Sure, will add one. What would be the right testsuite? gcc.dg? > I'm not sure I agree about the whole thing though, I'm leaving it > to Joseph. > >> gcc/ChangeLog: >> >> PR middle-end/25521 >> * varasm.cc (categorize_decl_for_section): Place `const volatile' >> objects in read-only sections. >> (default_select_section): Likewise. >> --- >> gcc/varasm.cc | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/gcc/varasm.cc b/gcc/varasm.cc >> index 4db8506b106..7864db11faf 100644 >> --- a/gcc/varasm.cc >> +++ b/gcc/varasm.cc >> @@ -6971,7 +6971,6 @@ default_select_section (tree decl, int reloc, >> { >> if (! ((flag_pic && reloc) >> || !TREE_READONLY (decl) >> - || TREE_SIDE_EFFECTS (decl) >> || !TREE_CONSTANT (decl))) >> return readonly_data_section; >> } >> @@ -7005,7 +7004,6 @@ categorize_decl_for_section (const_tree decl, int reloc) >> if (bss_initializer_p (decl)) >> ret = SECCAT_BSS; >> else if (! TREE_READONLY (decl) >> - || TREE_SIDE_EFFECTS (decl) >> || (DECL_INITIAL (decl) >> && ! TREE_CONSTANT (DECL_INITIAL (decl)))) >> { >> @@ -7046,7 +7044,6 @@ categorize_decl_for_section (const_tree decl, int reloc) >> else if (TREE_CODE (decl) == CONSTRUCTOR) >> { >> if ((reloc & targetm.asm_out.reloc_rw_mask ()) >> - || TREE_SIDE_EFFECTS (decl) >> || ! TREE_CONSTANT (decl)) >> ret = SECCAT_DATA; >> else >> -- >> 2.30.2 >>