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 23E43385840C for ; Mon, 13 Dec 2021 12:15:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 23E43385840C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-147-bvvJDeG7MhuDwYl2iy1eWA-1; Mon, 13 Dec 2021 07:15:08 -0500 X-MC-Unique: bvvJDeG7MhuDwYl2iy1eWA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 82EC55A064; Mon, 13 Dec 2021 12:15:07 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.17.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A8A96196E2; Mon, 13 Dec 2021 12:15:06 +0000 (UTC) From: Florian Weimer To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader) References: <87h7bjmnt0.fsf@oldenburg.str.redhat.com> <026b3d7a-7de3-3f7e-d59e-85fe7514eb54@gotplt.org> Date: Mon, 13 Dec 2021 13:15:03 +0100 In-Reply-To: <026b3d7a-7de3-3f7e-d59e-85fe7514eb54@gotplt.org> (Siddhesh Poyarekar's message of "Wed, 8 Dec 2021 22:29:01 +0530") Message-ID: <874k7c1z20.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.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.8 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_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, URIBL_BLACK 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: Mon, 13 Dec 2021 12:15:17 -0000 * Siddhesh Poyarekar: > On 12/8/21 15:16, Florian Weimer via Libc-alpha wrote: >> The glibc 2.34 release really should have added a GLIBC_2.34 >> symbol to the dynamic loader. With it, we could move functions such >> as dlopen or pthread_key_create that work on process-global state >> into the dynamic loader (once we have fixed a longstanding issue >> with static linking). Without the GLIBC_2.34 symbol, yet another >> new symbol version would be needed because old glibc will fail to >> load binaries due to the missing symbol version in ld.so that newly >> linked programs will require. >> This needs to be backported to the glibc 2.34 release branch as >> well, >> where hopefully all distributions will pick it up eventually. > > ISTM we could move symbols between ld.so and libc.so at will, without > bumping symbol versions because they'll always be used together. In > that sense, maybe we should not really consider such moves as ABI > events at all? It's only possible to move symbols if version nodes exist on both sides. Therefore, this patch adds a version node to ld.so. Without the version node, a binary linked against newer glibc will start referencing GLIBC_2.34 in ld.so after a symbol move to ld.so. The lazy bindign consistency check for symbol version nodes in unpatch old glibc 2.34 will then reject to load such binaries, even though a symbol definition would be found during binding (as you point out). Thanks, Florian