From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 2C3783858D28 for ; Fri, 4 Feb 2022 16:05:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C3783858D28 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 562CF1F382; Fri, 4 Feb 2022 16:05:29 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 43197A3B81; Fri, 4 Feb 2022 16:05:29 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 389BD64FA; Fri, 4 Feb 2022 16:05:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 36C586291; Fri, 4 Feb 2022 16:05:29 +0000 (UTC) Date: Fri, 4 Feb 2022 16:05:29 +0000 (UTC) From: Michael Matz To: Luca Boccassi cc: Fangrui Song , binutils@sourceware.org Subject: Re: [PATCH] ld: Support customized output section type In-Reply-To: <5483e1b249b67e143c540362213625cf1dccaefb.camel@debian.org> Message-ID: References: <20220202071044.1480421-1-maskray@google.com> <20220202183206.fhnivs3kb4ntnkmp@gmail.com> <20220203194656.ljthsfag5chdzadb@gmail.com> <5483e1b249b67e143c540362213625cf1dccaefb.camel@debian.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Fri, 04 Feb 2022 16:05:32 -0000 Hello Luca, On Thu, 3 Feb 2022, Luca Boccassi wrote: > I understand you don't like it, but as I've already explained again, and > again, and again, it is needed, and frankly I'm getting exhausted. But it's not, you are wrong on that account. It once was necessary until the problem (of generating writable sectons by default) was fixed. There was only a very short time window when (READONLY) was supported _and_ necessary. The bug (PR26378) got fixed in January 2021 (so 2.36 should have it), and since then we have: % cat x.c int main() { return 0; } % cat metadata.ld SECTIONS { .note.foobar : ALIGN(4) { BYTE(0x42) } } INSERT AFTER .note.gnu.build-id; % gcc x.c -Wl,-T,metadata.ld % readelf -SW a.out | grep note [ 2] .note.gnu.property NOTE 0000000000400338 000338 000020 00 A 0 0 8 [ 3] .note.gnu.build-id NOTE 0000000000400358 000358 000024 00 A 0 0 4 [ 4] .note.foobar NOTE 000000000040037c 00037c 000001 00 A 0 0 4 [ 5] .note.ABI-tag NOTE 0000000000400380 000380 000020 00 A 0 0 4 % ld -v GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.37.20211112-3 As you can see, no "(READONLY)" but still a read-only .note.foobar section. (Ignore the fact that my contents of .note.foobar isn't a correct SHT_NOTE content) That's what I meant with ill-advised: a feature was added to work-around a bug, instead of the bug being fixed. The bug now is fixed and the feature is useless but needs to be kept for backward comp, except maybe it could be removed again if the few users could be convinced to just not use it anymore; so could you be convinced? :) Ciao, Michael.