From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by sourceware.org (Postfix) with ESMTPS id 7F7523858C2C for ; Wed, 2 Feb 2022 18:12:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7F7523858C2C 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-f46.google.com with SMTP id bg19-20020a05600c3c9300b0034565e837b6so2926886wmb.1 for ; Wed, 02 Feb 2022 10:12:51 -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 :references:user-agent:mime-version; bh=c5PSnBdTBLGxBX4bjVD3O7RkkYQS8KIQz6C4vw6lLnM=; b=eK/s0XWlzoWoQTE1HkH6k0e2r/xHZZ45vzMl4NieHcy8NJ5weHmOZqkz4DLJSVljX1 blO7+Doz6NslVWYwPwyMzL+WwpB2Q/vUcIaM/hHcTTQzD/y+F2NvfGVm3FtP2oBJOdJg U6IdHBCZXHsnHLwZ+iTWiSS/GN/jS42MwVmFOhZUZkdSpa/ZenwLIQHX6fRoCM529EiM ri8FBRZG50Zk/NGEcuxXl2xn0eoBZu/6CodDtPvUj6/9iOBdrv+XyKcYM9LZIAVddnuU awT+mRUEgJsj5Nz0Rl8+pWaiaBttBrYXYcB51y4Gf2MWqoe+Xu4C4/BdFbPTIashX7lw PamA== X-Gm-Message-State: AOAM5304O4Ao9vbfdpvj9U9ttD+NCR8VKQLkUMS9fzan7vYHhPzCwAL0 spj4t4GzhKQyaiw8+iSS61+80HHka88= X-Google-Smtp-Source: ABdhPJzhQFmJjpsdUPPE16CDoiESw7ALWDqDfmwlnIa3JI58Ul5cPawzTTXYYg9+AgOFsJNsczQb4Q== X-Received: by 2002:a1c:4604:: with SMTP id t4mr7186820wma.191.1643825570066; Wed, 02 Feb 2022 10:12:50 -0800 (PST) Received: from localhost ([2a01:4b00:f41a:3600:360b:9754:2e3a:c344]) by smtp.gmail.com with ESMTPSA id n15sm21949505wrf.37.2022.02.02.10.12.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Feb 2022 10:12:49 -0800 (PST) Message-ID: <740fedd2111e72f785bbe000890193f55a6a1d6d.camel@debian.org> Subject: Re: Output section type (READONLY) From: Luca Boccassi To: Michael Matz Cc: "binutils@sourceware.org" , Fangrui Song Date: Wed, 02 Feb 2022 18:12:47 +0000 In-Reply-To: References: <251473f45c9c4d2fa5edc3265c5ac77e06bb07b2.camel@debian.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-+EyRXBf8qW71SGZBkOVQ" User-Agent: Evolution 3.38.3-1+plugin MIME-Version: 1.0 X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, BODY_8BITS, 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: Wed, 02 Feb 2022 18:12:53 -0000 --=-+EyRXBf8qW71SGZBkOVQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2022-02-02 at 16:54 +0000, Michael Matz wrote: > Hello, >=20 > On Tue, 1 Feb 2022, Fangrui Song wrote: >=20 > > On 2022-02-01, Luca Boccassi wrote: > > > > > For READONLY, I am thinking more in line with "whether we need th= is > > > > > feature at all"... If no input has SHF_WRITE, the output naturall= y > > > > does > > > > > not have SHF_WRITE; if an input has SHF_WRITE, chancing the outpu= t > > > > 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_o= bjects#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 READONL= Y > > > > keyword: > > > >=20 > > > > =C2=A0=C2=A0=C2=A0SECTIONS > > > > =C2=A0=C2=A0=C2=A0{ > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0.note.package (READONLY) : ALIGN(4) { > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0BYTE(0x04) BY= TE(0x00) BYTE(0x00) BYTE(0x00) /* Length of > > > > Owner including NUL */ > > > > =C2=A0=C2=A0[...] > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0} > > > > =C2=A0=C2=A0=C2=A0} > > > > =C2=A0=C2=A0=C2=A0INSERT AFTER .note.gnu.build-id; > >=20 > > 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.... > >=20 > > In https://sourceware.org/bugzilla/show_bug.cgi?id=3D26378#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... >=20 > Agreed. >=20 > > The next thing I feel uncomfortable with is the abuse of .note* indicat= es > > 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. > >=20 > > I shall add a note that gold doesn't magically set an output section .n= ote* > > to SHT_NOTE and this behavior makes a lot of sense to me. > >=20 > > 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 > >=20 > > =C2=A0=C2=A0=C2=A0.note.package (READONLY) : ALIGN(4) { > >=20 > > switches to > >=20 > > =C2=A0=C2=A0=C2=A0.note.package (TYPE=3DSHT_NOTE) : ALIGN(4) { >=20 > Also agreed. >=20 > (We can't remove the implicit .note* -> SHT_NOTE behaviour anymore, but i= t=20 > shouldn't have been there from the beginning). >=20 > > > > This turned out to be problematic however as gold does not support > > > > the > > > > READONLY attribute, nor the INSERT AFTER directive... > >=20 > > This is the reason that I really recommend a synthesized .o file, > > instead of a synthesized output section description using data > > commands... >=20 > More agreement. I also think that the synthesized sections should rather= =20 > be thought of as and handled like (by ld) input sections, going through= =20 > the normal linker processing (which would remove the need for "INSERT=20 > AFTER"). That's a largish change, so not something we can do now anymore= ,=20 > probably. Compiled object do not work and cannot possibly work sanely in this context. It is hard enough to make a simple and trivial linker script work reliably across ~30.000 packages with god-knows-how-many different build systems on a dozen different architectures, so it's just not going to happen, sorry. Linker scripts exist and, to the best of my knowledge, are still supported and supposed to work, so we are using them. > IOW: I think the introduction of READONLY was ill-advised :-/ But, ...= =20 > well :) If you have an alternative solution to make a linker script create a read-only note section to be inserted after another section we'd love to hear it. So far we haven't found any, but it's possible we missed something, of course. --=20 Kind regards, Luca Boccassi --=-+EyRXBf8qW71SGZBkOVQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmH6yZ8ACgkQKGv37813 JB6EoBAAtO/BDzan3t+fk2Vf9lHRusxcpxVE0bq+qdFcIEz5Q7q27N0s4Oh6DKYN /Z4p6VctpsTLphSLSNBZsLZFYXWbpA4SZZMZYAtqSBJF/YYPtanPUJ+LY44vTzfr rM12hddlwS38ZVEfUiKnTyhwtDh+qXcKznKJ9xlAXDzrsWn1vByEMysLM0fyYOVa Ut1mQJkXbFulhnGCn3shh+yuUMiXvxZZ0yZ83D1KZvH1gioglxE6elJRdOb0+H7e 06l+V2VINSTG4Kg+81XN+GVlBQZaK/RJMVQm6p31IIlHZgHplb2caAT4C1lS1DSm n4VDYVSZG60EtJzjHXDr0tX8XIyTq0TycuS+9iZffcVUhnPBNCTjHGxpxZQ/kMHC AD0eJeWCD+c3MqZZkO9Pb/10gYWasYafFHz/EMaJ1lQBtfmQSfYWnofFA01MQuI9 dxy/DrxGKJpXcR+Qe/hNONkgu/fBjIITLHUBZoTyoSXtFSv20rHvaG0Su75JKQjE UA9hkxNaY9Yg4ci//TEyJ5csVMJOrF351K1ONi1xy6Doiye8sbbQUfVgEK0oSH+g yLqp7iFfuDkjqW+GQcRcqLo5dBKhVcbnXIOsa4K2TJJLz1c2ZADYzJfeshYEUrbU 1s+NMrVMPGOfMAcJT+UB3KFlBJVp+V89HMbAVv2pOBU1xxMEsoA= =SlZG -----END PGP SIGNATURE----- --=-+EyRXBf8qW71SGZBkOVQ--