From patchwork Fri Aug 5 01:26:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jose E. Marchesi" X-Patchwork-Id: 393 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:b5d6:b0:2b9:3548:2db5 with SMTP id v22csp738721pxt; Thu, 4 Aug 2022 18:27:33 -0700 (PDT) X-Google-Smtp-Source: AA6agR5uW8zpIv5vP3p4gkhsycnSo/iSfIuk4XP+wu/EXLJvoVEM+7SeACJpv4uDmGUZ81eZv4Ph X-Received: by 2002:a05:6402:280f:b0:43d:f946:a895 with SMTP id h15-20020a056402280f00b0043df946a895mr4537237ede.229.1659662853238; Thu, 04 Aug 2022 18:27:33 -0700 (PDT) Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id bm25-20020a0564020b1900b0043cc4d599f8si2534837edb.161.2022.08.04.18.27.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Aug 2022 18:27:33 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=JEg7Gbhi; arc=fail (signature failed); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B74FD3857BA6 for ; Fri, 5 Aug 2022 01:27:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B74FD3857BA6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1659662851; bh=T5qnr7eL5ZwDLHSHItNiPBiE3Zd7UcNMCmEMVetlYD8=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=JEg7GbhiIT5McGzRU8H5Wsw5za9nDGFIximLbfFaxHXSO9SyExdvqFzKW1Mk90Dq6 m1vHa6jaWtRnXkvyyDRPG1k3G05Bm32l1t0TjcQ55xY4pX5H2SUFSAHSLRZ2aJ5QcR 3QEcOKyN8QS0i4ap4RHE0VCTR/WySdJwhCrh+5iM= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 0810E3858407 for ; Fri, 5 Aug 2022 01:26:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0810E3858407 Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2750EXnn027743 for ; Fri, 5 Aug 2022 01:26:37 GMT Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3hmue2xm3b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 05 Aug 2022 01:26:37 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 274Mj7dr014118 for ; Fri, 5 Aug 2022 01:26:36 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2107.outbound.protection.outlook.com [104.47.70.107]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3hmu34xfa5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 05 Aug 2022 01:26:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hdwckyz+7Yx0Y1eXK4hcajXrzfF/UIdPe+CN5TuPSikbNtpQ4b5HXqx6VlB36UAiABNfScGzoME988vB9qR3tQGEwXrQ9ffLRc/rTeBX0XEjSOENySG9ff8G6fP1Lr1AuTOojxpNJzfFsIKvg9qYc4R8WCBpeKXx9mOvabNcvCc5EFKhIdudkCR4MT2Ft1xyg0ke3aASWvkpMG9irR307lCfmLQ0tD3dErNgs14RKeuhLfAAZN95JNWZ4E4YrrG7ZkR2eiGuCz4okh1oFtSe5gvmYQmflwmch/cncG7AUvMTk1NkWtCGIhueRmzxxb45FGEAJml+WUo7V/sPKdjOyQ== 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=T5qnr7eL5ZwDLHSHItNiPBiE3Zd7UcNMCmEMVetlYD8=; b=n3zoTmuBZiBFUPTmCW2qcvK3I1h5di5ArfoxKk0KvbZt0wjpQABiJTROsLk7R7WfAXpiQo6kTHiLVzhMNm4xhL99r2Nl9zDSr0ZEKvoTo5JVxTnArSWb4CCU1Rl+u0fxg4AqQ/sXJtdc6KI8I/ycBhK8+EZxhdnJy1ASO2KWPqZP9w442r5d3eQSelxpqBz6OymauZPsnDWGdsKihJhVMHcjLwxave8FkRdoMFSJ82NhJE7lwB37TYCj+v7BrvjPE3GYZD0fHMOjg9UHWCO1aF65ni4kPoa62163fKzVsAYl0MFfcGGt6Rc+9NAMPc1L/t3jpJdlxZJ2PM2TlHi9NQ== 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 CH2PR10MB4216.namprd10.prod.outlook.com (2603:10b6:610:7d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.14; Fri, 5 Aug 2022 01:26:34 +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 01:26:34 +0000 To: gcc-patches@gcc.gnu.org Subject: [PATCH] place `const volatile' objects in read-only sections Date: Fri, 05 Aug 2022 03:26:28 +0200 Message-ID: <87sfmbxyyj.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) X-ClientProxiedBy: FR3P281CA0103.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a1::19) 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: b9f3cd1a-45dd-407b-da34-08da768188b6 X-MS-TrafficTypeDiagnostic: CH2PR10MB4216:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: L4aUj32sBvSCuKrSPOdGX7tWgyeQFH4D0hBx9Ll3mC/emSDRYHyPbsQG9uwvCuKjp95tnoFhNeUgGoq4Z2AjOuHM3oMb+zM1BYsqVB16FNmwTRbA9wxYSjPftYeMJQw/czZl4zLzoMzRp6iIDSWboJ5Mz51psR3ERcaFS97cfCKRCjPQus4eVosc/S6hGuygPy5TdnYM2ldFXPc1XUQ0ZXuTgol5JmSGv7EUDGpYyRZNjd4r/7zA+nNdSO8RNalIr3sK4GtBcispnVkIw4XABFh92OZzJ63z8BZcduk7I2SL24eUHsKLMTQGVts9htOmfucjSYgk3QQVVXOc11MfSo/VrHw1ISeNSZSWwx28cLHq1g5Br+3iB5rcgmrQILMia46/KW7FAx5myaccWpDfdFZ3tmUk9CXrgmcavc1s/ACKmy+2KdfbxeDPAQxWamdZttJCk/KzCYdfHKvtjJ7MaTxWItamM3atsMrgLqHPQ5VGaE7YC7R0+1FXkMGH7GWZw1zy6rFNAApaa/e2YcH7i7XMwFaeeNWlSQuCm33lZy3b60out57hqhQPErt04zTNps6k8CHQmyk9hxB9TiDlEqwgS4AZUC22eld3rSEtWwJbABbzUu6mEQeTipRM7336zCRUuGXMn5Im54VBYJ5iig1CXIa7oa7bbQJWto9I1rFRIdXYlbg6j3Q7NcLRYrtgSYDaTufEq0JDr/jSwLDqrJ76gNljFzEVi7cl/olgTQ1/LRUvthjo8PqkG59J7FR8blJVKaKwso73YIdllH1vDpK8ILz+BnFfDZS4MyhvzkpYu5fs5MIGKpwJ92DWk8qu7zU1VuWsac0uYt9wT9xXLUQ43luT8DWf/m+9byorNOInW49enuhBd1cG9UfNmVX8hdsgxcsKdV8g9rofbUFUXQ== 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)(376002)(396003)(39860400002)(136003)(366004)(346002)(4326008)(66476007)(66556008)(316002)(6916009)(66946007)(8676002)(8936002)(2906002)(5660300002)(36756003)(38350700002)(86362001)(107886003)(26005)(6512007)(52116002)(6506007)(38100700002)(2616005)(186003)(6666004)(41300700001)(478600001)(966005)(6486002)(83380400001)(81973001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: u0ODxe2Nlq44uDCwtsT+JU3HYtMDknZU0VI4tXQ974Uc6HUrSSKBkO2dQglA+N4O2imdVHt9HJLTU5kMIg5Ff+cQF47/lISRhkVtTqULPNtWPN1FyyLaerZF+OMjZnX0puL1DrZV89xIFMzM/FppFtE5iNx1inBNYz3mwQ/NODg9CbdAsWQGT/+HvruwfODnmnPwW9BrjVvE21ENCRrcDlP5gmGmGe3We3/O2w2lHfk7Qj7bmalD1FTMvKals/5vc0Ai4Ti8fy9VhURrOTtIUqbO244EG1jKlSR33nQRod4bNDxhP/MQg7ghaADTaQaFHOsmt4lLKqoTHVtigZUieZcd20NZJO93ibd8dY0OIOAPAGln1+41kImLTjAXXlhcUMLdJk/Edwfc96rNVhsHi7tGCKcTWEawd34G+gQV7odxnkSXK4dx0xmfwK3OxbNHBmyV8TRcRl8Mf7Tx2v1WSiTKjnCqEYu3FG6FRRa3TMlBcjL3x7pRfXgzpu9CtYKbG6ds2QInWopZ89+HIdBSzy4lc35W2JiG/cDbXXWgSzEjJo9XkLAnNhrC+xSGtAl3pjSlbRlj5kaPFj1Bk4TcN+JyGI4CUMWdD3PUY6JZi8diMnPnqrOd0f2CJMBo6mOgN6jpEEv17tlPGBEzY8+xzDihe3RLwHOfbI6x2TuA/iVKznoHvltXgXwLDnSxqo8YwLYJ+o27qa/8S8fGCeGRt8LtOW4FCwEiG2IUqwuGlC7OegoAOB+ShR8Z/u/pxusPWGkRmzmS3aeHXDKuaaBXejD3fXzM4ll88FeXmGy8F1hwxIJ5p3qgK0FjQkAOXKhk2i90AvmEP7c1cdwm48lWgcbjKki7ImNa7WW+T8hGLKXBIa6N0MWPyZaBymAFApYIrWBzUECPKPfVXRck0kwXQRqSkYAGOXtOi2BjU5DHoW4CiHzf79dVmGNWnmWrb/lWuDDJkaVgVCsL6sjeT3fbd5mQphxjH6/N9TkSOITVVEGfXtvHhSupr7KwEgMi8K4Cp66PHBkduBHxLDUByl2tBGUkVWha0OIyk6BXkCmPRJTdWLk/Cn00ji7fGRiwEyFiy7zPVtIzZR8AOpzQBIylpkkCH6wBZe7E5HBHZVDoVvzvgyXkyzG7jkhr5GZvOFviwV6pF6MHOZdvj2LysoBqPV4W69h9BwDiHkbACi3tqgaHSY8kkVh7wbzUBW9DHwK8fvybyIra3ehe/oskvdp4Rv4JI5RCaWDBAEWPTT5TEf9VmbGnUAvOgHun/3ElCYjaZ8crJI8vCF6KQNqIzbXYaGgEpoDTD7JWfTAsBVJnCiOiIO5N0JgiKacUtQII2zwo86GUtcfLidvfuSS4JwpSm6rt8/m2vVgJkhQ3YCn1RU0/201Ok1kPF4vF5X7e8rpm54O7eHFNWoIlD3eAk/WcQb58zzq0npDlg2d7cPsjiaZZ55meF3iRToYEKbwWH0TwbljJM15gaIv6Y5EfTdtlW4p5tggVm6mDteCOiTvEcSm5gLJPFWJqeF7oMjsNGydJUIhPFsi2NJ2zfnS2Ve3Ih7YjI3TPEyR4VLrTrlGbkaPecjL8E/jZ2qakE4ERVCD8Kom2rKnIztXY5FGmDjM1qA== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9f3cd1a-45dd-407b-da34-08da768188b6 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2022 01:26:34.4296 (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: S6OsagvwE+Wzjehkkyf3QMVOqlPp8+BsHl21A4DoZD492hexLrgR1dO0gm+n1vG2Vuxontga18iMbBEp7HNA32JLLsla2DwG+3etfEWWzos= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB4216 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-04_06,2022-08-04_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 suspectscore=0 spamscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208050006 X-Proofpoint-ORIG-GUID: PtW_NEcgaKSAhmbBRTlczsyMSkzR7Rwn X-Proofpoint-GUID: PtW_NEcgaKSAhmbBRTlczsyMSkzR7Rwn 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 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-Patchwork-Original-From: "Jose E. Marchesi via Gcc-patches" From: "Jose E. Marchesi" Reply-To: "Jose E. Marchesi" Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1740282636159434589?= X-GMAIL-MSGID: =?utf-8?q?1740282636159434589?= 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. Regtested in x86_64-linux-gnu and bpf-unknown-none. No regressions observed. 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