From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12olkn2101.outbound.protection.outlook.com [40.92.21.101]) by sourceware.org (Postfix) with ESMTPS id 51A623858039 for ; Wed, 2 Feb 2022 07:36:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 51A623858039 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=maskray.me ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ilI7Ci7KZIf+tbPvcrae2iUuDioWDiGgyOP4wTYBSas7Uy9eKOXzMZeIsI/xr4/nEh/h1wQcIPaa543tPXYV9ZW+QKVef2X34e2CdHG92eE5eYj16qBBHOdDbi9vnRt9nz+kegEtid+jqX0AiyqoV9I/kCPdx1WkEPPle/n64WOPNOSk6YYhSWrMagI1T/dgaLR10TnMzJo/JKypUoM1g+kOrqPNwbG/2dthRsyEIYVtIc9de1C6kDuTWEpumA+ScDbPwGx7yjrwwkb3vr0HXe0w4tnDqdhHrmOECb1db+xT13c/kzp7Ki3fjRfNrUhqIPxIy+r7hdrf7ArQjqNcSQ== 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=as1tjUjonauxQxqkgTSirn/HgrQtdaNkGfVRsdnDOQk=; b=aszUA7zc4HwNE4rfE0dm/vJ1dKUXvC4thyCoKCfTsX2o2GF00NjxYfdRVcl6zFyJ/htNwr+45itFub3BnfXWGvXpdqAmr2oT9+WgDLvCXCmmoG6E4TEyGFcwl/32sObApBZAEhCi+D9TcefMPIAXZZcvkpScf7yYU3hKzRitdsKmGTL97f/fb5lWE4LhcWCtPt7fPdcRaBBDUpIET6GGjt42YkDR+DPU/mnF9zfAioRPD8DVv5mLgTlL4Y2wUe6BoUaKlmJG0xZqdZdYsVrQUbUFR2LaYP7vTB89YDVpOgSvM157NGBoWDg/L88RpDmdjPZmWg5nWbI6qYD9+ParoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from MWHPR1201MB0110.namprd12.prod.outlook.com (2603:10b6:301:56::8) by DM6PR12MB4793.namprd12.prod.outlook.com (2603:10b6:5:169::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Wed, 2 Feb 2022 07:35:45 +0000 Received: from MWHPR1201MB0110.namprd12.prod.outlook.com ([fe80::e5fd:489e:8c97:8bdc]) by MWHPR1201MB0110.namprd12.prod.outlook.com ([fe80::e5fd:489e:8c97:8bdc%11]) with mapi id 15.20.4951.012; Wed, 2 Feb 2022 07:35:45 +0000 X-Gm-Message-State: AOAM532fXKTFhngHfX+fjjj/13qqEHJzUlBxJEyysTdIVNVLPlp5jMh4 w6ovSPKJQ/lChrvWcsBloGU0suHSjYzn78oQk6c= X-Google-Smtp-Source: ABdhPJzgZ6AGL/WISD/BvPwCjd5b7dX8qJLXUC4BWTAV39LZDtNiqhD5StJUyY5nnKx5aYnoeKMAjpQW7v6I5I5+NyU= X-Received: by 2002:ab0:6f0d:: with SMTP id r13mr8895379uah.114.1643786963007; Tue, 01 Feb 2022 23:29:23 -0800 (PST) References: <251473f45c9c4d2fa5edc3265c5ac77e06bb07b2.camel@debian.org> In-Reply-To: <251473f45c9c4d2fa5edc3265c5ac77e06bb07b2.camel@debian.org> From: Fangrui Song Date: Tue, 1 Feb 2022 23:29:12 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Output section type (READONLY) To: Luca Boccassi Cc: "binutils@sourceware.org" , Alan Modra , Nick Clifton , Cary Coutant Content-Type: text/plain; charset="UTF-8" X-TMN: [E793NuMuj+cxX85ALRymR0pNa/xKw9qT] X-ClientProxiedBy: AM3PR07CA0056.eurprd07.prod.outlook.com (2603:10a6:207:4::14) To MWHPR1201MB0110.namprd12.prod.outlook.com (2603:10b6:301:56::8) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2143c51b-9148-4f26-c228-08d9e61e9f7f X-MS-TrafficTypeDiagnostic: DM6PR12MB4793:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XSNRJkeaJhbIS99pW5/avZoce3YZGpfenc1Z7sza9gOOspA1oVe8K68lhsBanaVwB/65+IZs6tNwa93WiLaD5jbcSJWAWFSnQzDjRlFwpzf4TeOXjijZXfXjYevncS1/7hLf5JBqEpaXdi7kLXgyZfhWfA13bsiA+YViy2Pty+YNgsB4G++s74F4cgEYqYTcFVjUKg5RFJ6o2M5uE6pCtWVlRB6EvX8361wQ8hlMolm4mKMpRORgkEU7c6ItjcBGycUoz6IqEE/AAKQFczK2l3UZI7J4RbqaICrgW+KkUQ5oigg1wFyIf7moxIv1xtwMg6gVmfPSJmQc59owYuU9WINNKkH3bPwhDc1c7m7HBQ3u3kR8KuCxah6SR1e2p/l6mszTVJvcZ/ShhkWBIs/YBOs9mnJZCbTvXpio3O0MlaB5eRKRz+OrcP+ZG0BuaQyhWjVniyCOB7ZwS3tAj/y3YP+xaLpCi3LcwWZVaF8OuX1eO3eeZqwG/Cwq9JG4N39SI0PPQe05+B3p2nZhjHRhTIKLXFQAUWBdT8T9dB/oU4L9G1SJl/DnXAd094mhgFPMP2ghMB19J8g62+HXzgOD58pFWkJBbduCH6bbvm70nVfquZ9j8u0ljGRCdRICaygq X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c1RoZ2cyamlxSkF1RlVHVTcrcDUyemR3ZVo3SVpVb0VKSUQzUzlhRDIybFk4?= =?utf-8?B?UmQrMEpnZVU5SHlocmg2MGErQ0lrRGpUL0RMMUNUZ3ZCR0J5a1ZhcXZ0VUV4?= =?utf-8?B?K3R3cDgwV2pIdGxVbkFONm1UalJQb3EwVmJQVGRmaVhCaXB3RVU0Smg0V1BO?= =?utf-8?B?T0QxL1JjcDdIeW1IaENCMEhHWW1ZT0FWNXhTdWlYMDNaZDBRQmV6cDhtK3hN?= =?utf-8?B?YWluYmg1UEpYMnU3OUp0cWhqVk1tOFZzcHVwK3prNlJHcCtDRFRjTUpHYVdv?= =?utf-8?B?b0l6cHBZYkFqdGhWcUtVNk5xdit5akt2M1hrS3g2bkEvMktWVis5cEJWd1Zx?= =?utf-8?B?U3gxZzc2dGFhSVQ3aFN5ZjBSbDVvOTRnUnpMaFZURjZJRnJoMVpCRzhaaWxE?= =?utf-8?B?OGtSS0FncSsvdmVGWFd6dU16YUMxQkcyeDFXcVV6ajgyWElwY2tjdXhIa2hU?= =?utf-8?B?ZTMzTzNsYnJmdDVLRUswRUgvYzJublpBbHNJdVpqblYwQnc1R2o2SlRIYS9R?= =?utf-8?B?RENuaG5UN2w3QlNETmltSVFaTFVpbVgrMEx0L0kwMERZWG85VHdUUm00Z2hx?= =?utf-8?B?YU44ck5VdDVNUmlnRS9LeFczZk1xSytsYkg1ZWI4aU9OREYzQ2MydkErVUdp?= =?utf-8?B?T2QvY3hDT3p6RFo3TG82NGxzM0t5aUp3M3d4d3pHRTZueWFCV1Q4VDhHM25G?= =?utf-8?B?MVJNcTNXeDZ2M3hMamc1SGZRSnJUaXh6Z3pubTEvVFVZd2tVeEpTMW1SQ0VI?= =?utf-8?B?MWc0aGViYkZMUVdMaXVYTnZubzNFQUlmZ3M2YUEyaldSaUlISWZBMHZPVWNQ?= =?utf-8?B?SFpaWkVDVlU4WHJWWE9kMTl3ZHpDV0UwZDIreFFqZ1dUdmtYN2hZQUxhR1pk?= =?utf-8?B?Q1I5bWk4QmJyM1RUWFpQbmMwMVVzVUNtcFpFdXIyTXd6QkZkdnNuWmxrYUZE?= =?utf-8?B?SFp0aUF0RG03VTZYdWFYdDh5cWtLL2FDdm5ucW8rNW5ZMFVwbGFtNUlXRjdL?= =?utf-8?B?ZVUzb29wcm9TSWVPZFFoQjl6UEI0U3AwZE1CMjNZZ3cxZWFaMk1tREMzWWpv?= =?utf-8?B?bURXdndqOEtOYWc5NkRJdGMrSktxeWcrOTFnMkNnUi85ZFdRbGNMUVMxWXk2?= =?utf-8?B?eU1objhkZ2pBTTB2a1BaTEFuemtBNm94ZXpWMURTNUNxc25vWUE2Qlh5S0x3?= =?utf-8?B?dy9qRC84UGZEeU5mODJISnVqZVFzNDRtc1pRQjFnY3V6dmxuODg0SEtTeWdF?= =?utf-8?B?MGtaeEFSZUgweHFmazhKRjdOQ3RreXdMdCtSWVhFVGR1RjhuQT09?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-71ea3.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 2143c51b-9148-4f26-c228-08d9e61e9f7f X-MS-Exchange-CrossTenant-AuthSource: MWHPR1201MB0110.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2022 07:35:45.0243 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4793 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2022 07:36:57 -0000 Hi Luca and Nick, On 2022-02-01, Luca Boccassi wrote: >> > For READONLY, I am thinking more in line with "whether we need this >> > feature at all"... If no input has SHF_WRITE, the output naturally >> does >> > not have SHF_WRITE; if an input has SHF_WRITE, chancing the output >> to >> > non-SHF_WRITE is weird and error-prone. >> >> I do not know if this counts as a *justified* use of READONLY, but it >> was >> used recently in an attempt to add a new feature to Fedora rawhide: >> >> >> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#New_system:_.note.package >> >> The feature used a custom linker script fragment to add a note >> section >> into the executable being created, and this script used the READONLY >> keyword: >> >> SECTIONS >> { >> .note.package (READONLY) : ALIGN(4) { >> BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of >> Owner including NUL */ >> [...] >> } >> } >> INSERT AFTER .note.gnu.build-id; Yes, I recently learned that Fedora started to use (READONLY). The usage feels strange to me as .note.package should not have the SHF_WRITE flag, even without READONLY.... In https://sourceware.org/bugzilla/show_bug.cgi?id=26378#c11 , Alan changed such sections to be read-only by default in 2020 to support a Linux use case. I do not understand why a new keyword has to be invented... The next thing I feel uncomfortable with is the abuse of .note* indicates a SHT_NOTE section. The type, in my opinion, should be explicitly specified. In ELF, attributes are identified as well known integers. The magic section prefix ".note" is contrary to this. I shall add a note that gold doesn't magically set an output section .note* to SHT_NOTE and this behavior makes a lot of sense to me. To allow forward progress, I created https://sourceware.org/pipermail/binutils/2022-February/119591.html (ld: Support customized output section type) and I'd recommend that the linker script fragment .note.package (READONLY) : ALIGN(4) { switches to .note.package (TYPE=SHT_NOTE) : ALIGN(4) { >> This turned out to be problematic however as gold does not support >> the >> READONLY attribute, nor the INSERT AFTER directive... This is the reason that I really recommend a synthesized .o file, instead of a synthesized output section description using data commands... >Yes, we are aware of the issue with ld.gold, and are thinking about >what to do there. The main problem is that even without those >unsupported attributes, ld.gold generates broken ELFs that crash >immediately. For now, we just suggest to just use bfd whenever >possible, and skip this feature otherwise with a simple flag. It's not >great to lose debuggability and useful information, but it doesn't need >to have 100% coverage to provide utility, it's perfectly ok to miss >some packages. >> Anyway I think that the point here was that was no input section, so >> the author needed another way to tell the linker that the output >> section >> should be readonly. > >Yes, this is precisely the use case, and the attribute is working as >intended - not just in Fedora, but in CBL-Mariner too, and other >internal Yocto-based use cases. > >-- >Kind regards, >Luca Boccassi