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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id 064293858410 for ; Thu, 28 Oct 2021 14:08:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 064293858410 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-569-xxJHQeTFNL-V8ga45wXttA-1; Thu, 28 Oct 2021 10:08:36 -0400 X-MC-Unique: xxJHQeTFNL-V8ga45wXttA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4D185802B4F; Thu, 28 Oct 2021 14:08:35 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.250]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 26776101E692; Thu, 28 Oct 2021 14:08:33 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: "H.J. Lu via Libc-alpha" , Binutils Subject: Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED References: <87zgqvq03g.fsf@oldenburg.str.redhat.com> <87v91hljth.fsf@oldenburg.str.redhat.com> Date: Thu, 28 Oct 2021 16:08:32 +0200 In-Reply-To: (H. J. Lu's message of "Thu, 28 Oct 2021 06:37:48 -0700") Message-ID: <87k0hxkzrz.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.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Thu, 28 Oct 2021 14:08:45 -0000 * H. J. Lu: > I am not sure if I am following your concerns. We have an ELF feature, > like DT_RELR, which is tied to a glibc version. The binary with DT_RELR > will crash with the older glibcs. And you DON'T want such a binary with > a dependency on the required glibc version. Can you tell me why? Historically, such features have not been tied to a glibc version. CET, DT_AUDIT, AArch64 variant PCS support, nearly arbitrary calling convention support on x86-64 all are not really version-specific (they have been backported to varying degrees), and those involve dynamic linker features. In contrast, if DT_RELR support is indicated by a GLIBC_2.35 version dependency, it is necessary to backport all of the GLIBC_2.35 symbol set as part of the DT_RELR backport. This means such backports are usually not feasible. >> >> The problem that linkers and loaders ignore unknown types should be >> >> tackled in a different way, e.g. by flagging critical types in some way. >> >> See: >> >> >> >> Critical program headers and dynamic tags >> >> >> >> >> > >> > This won't help the existing ld.so binaries which this proposal >> > is addressing. >> >> We need to increase the ABI version once, to signal the requirement for >> critical tags checking. >> > > Which ABI version? .note.ABI-tag or EI_ABIVERSION? A binary linked > against glibc 2.40 without DT_RELR can run with glibc 2.34. But a binary > linked against glibc 2.30 with DT_RELR won't run with glibc 2.34 at all. > Increasing the ABI version doesn't solve the DT_RELR issue. The way EI_ABIVERSION works is that the link editor produces the minimum version needed by the features in the binary. So if the link editor DT_RELR, it would produce a DT_CRITICAL_DT tag for DT_RELR and set EI_ABIVERSION for critical DT tag support. Similar for other critical DT Tags. If no critical DT tags are used, an earlier EI_ABIVERSION can be used. Thanks, Florian