From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7014A3858C2D for ; Tue, 1 Feb 2022 11:07:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7014A3858C2D Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-458-QCGydMSPN2qZx1N3LMiiNA-1; Tue, 01 Feb 2022 06:07:33 -0500 X-MC-Unique: QCGydMSPN2qZx1N3LMiiNA-1 Received: by mail-wm1-f71.google.com with SMTP id v185-20020a1cacc2000000b0034906580813so1399030wme.1 for ; Tue, 01 Feb 2022 03:07:32 -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:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=ur9BWvFiNkkT+ULKasf160gWkZimyhytpy16cHWxWN8=; b=2uQ6KEaRPM/cHknjBDw/d8IoBoiZwMD+fm6dRf5b4TqfaXJFOBkYfBoAMw7c2QPlxw LVJiOPGiZU+2qw6IIjzsuarrHCMqI3gsUZjLrCGDEnV4F6gekrEjsJ5p3Vy0h3laVulj QYAx8MRZ7YnAkL3p3U9E/Cm1+D1SFMLIAdbxJlLfC6+6D4wZKI4ZLWUCJkN+2JGR9Cw1 gbW8g9nz3kgZ9qcahHO4xxmwLljtT+bydcbCzVOhLSUvg2BEPDM4UMq4GvgOmGhSriz9 X3TgwJaeTLHgEdE2KzRE5e27lZjnV4MS3UaDG/kmE1PKRBw1nPH/V9QFGQ8IQi24oVhl 5rEg== X-Gm-Message-State: AOAM5333Jka+UgPssse8Q7h3k5HCILcrKzIs2ws6Wlo0UunAUkcumx6D DWN8r1EQwRVhjJ1LN6ErF69I1GJV1JezxTg74DalR6L/U1kIAHjACARWojrQ55lyWvXZUFhxqsE akGhk8NPykceNiEd5Fg== X-Received: by 2002:a05:6000:4d:: with SMTP id k13mr21180107wrx.625.1643713651722; Tue, 01 Feb 2022 03:07:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJz6jcNwMqPkSJ4wupYAwi+DujN8fSg1gS8HeiKc1ZU0BgQ+b12auDmWyY2EwEAuf3Oi7f6mnw== X-Received: by 2002:a05:6000:4d:: with SMTP id k13mr21180093wrx.625.1643713651568; Tue, 01 Feb 2022 03:07:31 -0800 (PST) Received: from [192.168.1.6] (adsl-164-239.freeuk.com. [80.168.164.239]) by smtp.gmail.com with ESMTPSA id j13sm14421343wrw.116.2022.02.01.03.07.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Feb 2022 03:07:31 -0800 (PST) Message-ID: Date: Tue, 1 Feb 2022 11:07:30 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: Fangrui Song Cc: Alan Modra , binutils@sourceware.org, Luca Boccassi References: <20220129074545.csaig4kn5bk4si5k@gmail.com> <653b3fdf-61ed-2c41-5db2-de40bb51e8a0@redhat.com> <20220201033930.ssqtsoha6jaqzsfs@gmail.com> From: Nick Clifton Subject: Re: Output section type (READONLY) In-Reply-To: <20220201033930.ssqtsoha6jaqzsfs@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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:07:41 -0000 Hi Fangrui, > 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; This turned out to be problematic however as gold does not support the READONLY attribute, nor the INSERT AFTER directive... 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. Cheers Nick