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 091553858C27 for ; Fri, 24 Dec 2021 19:01:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 091553858C27 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-617--Co4so-5M0eF1dnbMdcuHQ-1; Fri, 24 Dec 2021 14:01:33 -0500 X-MC-Unique: -Co4so-5M0eF1dnbMdcuHQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D7D1B8042E1; Fri, 24 Dec 2021 19:01:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 05C2C84A21; Fri, 24 Dec 2021 19:01:28 +0000 (UTC) From: Florian Weimer To: Florian Weimer via Libc-alpha Cc: Andreas Schwab Subject: Re: [PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader) References: <87h7bjmnt0.fsf@oldenburg.str.redhat.com> <87czm7qv2f.fsf@igel.home> <875yrzmmw6.fsf@oldenburg.str.redhat.com> <878rwvqtyc.fsf@igel.home> <87sfv3l7ag.fsf@oldenburg.str.redhat.com> Date: Fri, 24 Dec 2021 20:01:26 +0100 In-Reply-To: <87sfv3l7ag.fsf@oldenburg.str.redhat.com> (Florian Weimer via Libc-alpha's message of "Wed, 08 Dec 2021 11:28:39 +0100") Message-ID: <87y2497rp5.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.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 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=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: 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, 24 Dec 2021 19:01:42 -0000 * Florian Weimer via Libc-alpha: > * Andreas Schwab: > >> On Dez 08 2021, Florian Weimer wrote: >> >>> * Andreas Schwab: >>> >>>> On Dez 08 2021, Florian Weimer via Libc-alpha wrote: >>>> >>>>> The glibc 2.34 release really should have added a GLIBC_2.34 >>>>> symbol to the dynamic loader. >>>> >>>> Well, the ship has sailed. >>> >>> Has it? It's just software, we can change it. >> >> ABI is not software, it's a contract. > > But sometimes we have to to fix bugs. Again, what I propose is quite > different from a simple symbol change because distributions and users > can fix this now, well before the symbol is going to be used. > > I have considered using a stub DSO and mention that instead of libc.so.6 > in the libc.so linker script. But I'm not sure how we can prevent users > from linking against the moved symbol by bypassing the linker script. > That would produce ABI-incompatible binaries. We could turn it into a > compat symbol, but as long as it's in the dynamic symbol table, some > people will use it. Let me propose a look at this from a different angle. Let's say we do not apply this change. Then if we move dlopen (say) into ld.so, it needs to have a new symbol version, say dlopen@GLIBC_2.36 (to enable early errors on old glibc even with lazy binding). The net result will be that dlopen-using binaries linked against glibc 2.36 or later will not work with glibc 2.34. Binaries linked against glibc 2.34 with or without the proposed change are fully interoperable (forwards and backwards compatible). No new symbol version/soname combination is ever generated by the link editor because the GLIBC_2.34 version in ld.so is effectively empty. Considering the moved dlopen, we would give it version of dlopen@GLIBC_2.34 (even if the symbol is added in glibc 2.36). Binaries linked against glibc 2.36 will still fail when running at the initial version of glibc 2.34. But with the proposed patch here, they will work even with glibc 2.34. This means that there are no ABI incompatibilities introduce by this patch, and we enable compatibility with future symbol moves. Andreas, what do you think? Thanks, Florian