From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by sourceware.org (Postfix) with ESMTPS id 0D6933858C2D for ; Tue, 1 Feb 2022 11:59:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D6933858C2D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f41.google.com with SMTP id l129-20020a1c2587000000b0035394fedf14so1659816wml.5 for ; Tue, 01 Feb 2022 03:59:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :user-agent:mime-version; bh=QVrv5355SpClbg+shfYFSXkpxa6+8yvYUDjQAXY603w=; b=pUUjsDUKx2P2FtT1XrbikFw61N0yL93mHmF7UB7sW8k0P4Z+Nsa2FmlaM+iBb3Y/E+ gE84M1cCVlzj6dgSezF8lt4wp50k7nFcJXUJSMLFHvffDwPsSE6uljkz2oY8ROq5rddw uxc0NNTeV8U4Qr8B+EgDXkc9kg6xWq2PjquhlK9ZzQEjYwEpD8/ZvBerBDyki+JdSfWU K1jVW6ejBxX6p+6I+7/JuF/JUQg09h8Zuyke/hg+l6vFVravrtTJuqiuPT1tl098+DWY R2pifbjaRljhsiA/7pubDNZEh81BxgsnTEeOuPgyf6/jDjgDQhZRegqmhgep/ZAWDvKJ rMRw== X-Gm-Message-State: AOAM533IKZoRQ2IW3sj/1oxxIRoe6WCpsOvWQ2F4Khl3IORiPxBLroqp T9/7wuOXvgPN/ilkcu5xudocNEvXGSk= X-Google-Smtp-Source: ABdhPJx1GhtNbiXgltC/2ZMefu6GCJfLCV2QT9oR/On1w4Hwyj18vSEQq737JYGNCx9wuhissUDGYg== X-Received: by 2002:a1c:f309:: with SMTP id q9mr1472806wmq.173.1643716765585; Tue, 01 Feb 2022 03:59:25 -0800 (PST) Received: from localhost ([137.220.125.106]) by smtp.gmail.com with ESMTPSA id j12sm14241317wru.38.2022.02.01.03.59.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Feb 2022 03:59:24 -0800 (PST) Message-ID: <251473f45c9c4d2fa5edc3265c5ac77e06bb07b2.camel@debian.org> Subject: Re: Re: Output section type (READONLY) From: Luca Boccassi To: "binutils@sourceware.org" Date: Tue, 01 Feb 2022 11:59:23 +0000 In-Reply-To: Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-vSXqvt+yjQGrsFYlV8um" User-Agent: Evolution 3.38.3-1+plugin MIME-Version: 1.0 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, 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: Tue, 01 Feb 2022 11:59:28 -0000 --=-vSXqvt+yjQGrsFYlV8um Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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. >=20 > 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: >=20 > =20 > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects= #New_system:_.note.package >=20 > 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: >=20 > 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; >=20 > This turned out to be problematic however as gold does not support > the > READONLY attribute, nor the INSERT AFTER directive... 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. --=20 Kind regards, Luca Boccassi --=-vSXqvt+yjQGrsFYlV8um Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmH5IJsACgkQKGv37813 JB7ZbA/+I1/qwKZ/rk6hJzKwHsCtD/Iiy0wlUadI45FM7g92t38H9DyJTa+HhGfg m5fQKxd0eRhKUZVmSRjQbHWrgc/m535FsOKVlUO5QB6hPiREOYS96Okmg/zZBRA8 ha7rOeycKGKTjIZSF7ES5sxjZBr08njYVXtnbJHnj98+r4USRhvq8r+NIFmJsBEU XHtk2rBfHI47wckeGQM3rL77jRegcG+iaxghvyL9bLM/Pdf8EJ5kh2aF512E2bSW W0phKrWCKk6JvR9yceXPfppzafSD4TiwMARSFL8tJHBV4EuUTaTY/NVO6O7sQsO+ 6lKS2OAiOyb9SNV6HuGFiOlVX6GIB3MScM6jbFECpejHzLyM7UULwj6MADYULET6 XjbTGVEYXq0SnlANpjOJH56+qTgHl7G7vu6LXM2uzut6FSXKo4BQ9MeQ8nmdXHYe FXAHpc8L5z7JSgt4Gk6bs1ujniiPHsB1guYdjAubSiRlzSpSC+zKgsGTfLvNk3Gt iQyMrNso4Ue3sK96lFecbGB2moMUQQ6IwPPHot+0UUAYm6cF+bzwHvTzqLDdmTWh V9+qDkQUZte2h1CvVWoah/rDNvvPBWG6VxyqJSptrstCrA2FZq7sJSiTlNbZ8lDy 9OmFqMdc09jqVenMyr3JavwqgWNhZuSMavN9wgRbfopHuU73yU4= =RV2r -----END PGP SIGNATURE----- --=-vSXqvt+yjQGrsFYlV8um--