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.129.124]) by sourceware.org (Postfix) with ESMTPS id 082A3385780C for ; Fri, 29 Apr 2022 14:55:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 082A3385780C Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-215-Q_XLQnrEMmW98WESywb2Cw-1; Fri, 29 Apr 2022 10:55:42 -0400 X-MC-Unique: Q_XLQnrEMmW98WESywb2Cw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 242D2383A5ED; Fri, 29 Apr 2022 14:55:40 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.187]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4472B145BA72; Fri, 29 Apr 2022 14:55:39 +0000 (UTC) From: Florian Weimer To: Fangrui Song Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v3 2/2] Default to --with-default-link=no (bug 25812) References: <15c7f6e9afe2c2b9c51ebc6372682a39b0932712.1649691083.git.fweimer@redhat.com> <20220428072502.4rpxnlreq72sgv5x@google.com> <87zgk5bnxo.fsf@oldenburg.str.redhat.com> <20220429060041.n24pkmlujglkumer@google.com> <87h76c74cb.fsf@oldenburg.str.redhat.com> <20220429074349.gna53j7ujgqql4ux@google.com> Date: Fri, 29 Apr 2022 16:55:37 +0200 In-Reply-To: <20220429074349.gna53j7ujgqql4ux@google.com> (Fangrui Song's message of "Fri, 29 Apr 2022 00:43:49 -0700") Message-ID: <875yms0wie.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2022 14:55:45 -0000 * Fangrui Song: > On 2022-04-29, Florian Weimer wrote: >>* Fangrui Song: >> >>>>How does lld place sections without a linker script? Purely based on >>>>names? >>> >>> It entirely uses code to describe the built-in rules like gold, while >>> GNU ld uses an internal linker script plus built-in code. >>> (some rules cannot be described by the linker script language and needs >>> code anyway). >> >>How can we make sure that certain sections are covered by RELRO, and >>still get start/stop symbols for them? > > About __start_/__stop_: > __start_/__stop_ symbols are special. They don't need to be mentioned in a > linker script to take effects for lld and modern GNU ld. I haven't checked > whether there is an ancient GNU ld which requires symbol assignments when the > output section description is specified. According to the BFD ld documentation, __start_/__stop_ symbols are only generated if the resulting name is a C identifier and the name is the same. That means that if we name the section .data.rel.ro.vtables or something like that (to benefit from .data.rel.ro.* placement), we won't get the start/stop symbols. If we use a C identifier name for the section, it won't be covered by RELRO. > About RELRO: > It seems that there is no section name convention to make a section > RELRO. Having a SECTIONS command with DATA_SEGMENT_ALIGN / > DATA_SEGMENT_RELRO_END can specify all RELRO sections. I do not know a > simpler approach than postprocessing ld.bfd --verbose output. > > To make GNU ld work, the following linker script is sufficient: > > SECTIONS { > __libc_subfreeres : { *(__libc_subfreeres) } > __libc_atexit : { *(__libc_atexit) } > __libc_IO_vtables : { *(__libc_IO_vtables) } > } INSERT BEFORE .data.rel.ro; That might work. But if we cut down the number of vtables, I think we can eliminate those special RELRO sections altogether. We have been slowly migrating off __libc_subfreeres and the like because having shutdown order depend on link is very non-obvious and problematic. For example, for optimimum results, we want to shut down malloc last on a thread. Thanks, Florian