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 1C4E5385AC1C for ; Thu, 13 Jan 2022 17:22:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1C4E5385AC1C Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-575-laAbgq1xNQeq6mEaGuBA0w-1; Thu, 13 Jan 2022 12:22:11 -0500 X-MC-Unique: laAbgq1xNQeq6mEaGuBA0w-1 Received: by mail-qv1-f69.google.com with SMTP id ke27-20020a056214301b00b004178da03fd5so6313324qvb.17 for ; Thu, 13 Jan 2022 09:22:11 -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:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=DZFIHImhRJnKjAMpDJX8znR71lTR61WhQaHVk4ojyHE=; b=PhtnyEVLBdFJFqqq+bkV++b2AL1Aa0lnv/B61US+4aUJNDdMqIdOn2uE5iGRqPI8wG EifsuOYEXgoTvxg9ufVJ7aEL3c4hWuTXpdar3Ad5Q5ZLF8IT9dwvJjdg3CUt3rZIckL4 OrcxzKGwaJURpYvEvkoFrGIv6FXOTScAQqr+9+sN9mhtY0nZ0+8SZDvqoM86Y0DDhnWQ CkiC6v0li+9JlHPxadAMhr2bwxiiMe3VHUmQItBRVz8t3/jXCnQ4cZ5rZIXPGtKBPm6a jjLsFUpiaU0ZuG+jZ5tWD0gx3ycWhFRCUyCT2NYQY6jX9d9mV6E9A/f7LExkIy9Kdyd2 ssGw== X-Gm-Message-State: AOAM531GocKwe1/K0ln4ChAd4thpn5azaKmUMfvcZcxAi+Rap2VGqVpZ SSc3tuc6IYpYEtE1YidSzjyjoC7+LFsUV0pCjrDVcTOpujt6a+HwCktT3HRk7M735sfnGGfd6Jk yLuq6x6/bNvfoz3gJ4/1I X-Received: by 2002:a05:6214:2a4f:: with SMTP id jf15mr4772072qvb.41.1642094531260; Thu, 13 Jan 2022 09:22:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJz7RltKVCE/N2QfbIo04n0f1TK79/tW6hgMVzY8KEVysjaIlwoPt9ILT1BCu6xGoXl2s4g9/Q== X-Received: by 2002:a05:6214:2a4f:: with SMTP id jf15mr4772062qvb.41.1642094531035; Thu, 13 Jan 2022 09:22:11 -0800 (PST) Received: from [192.168.0.241] (135-23-175-80.cpe.pppoe.ca. [135.23.175.80]) by smtp.gmail.com with ESMTPSA id y12sm2166485qko.36.2022.01.13.09.22.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Jan 2022 09:22:10 -0800 (PST) Message-ID: <606fcb45-254a-9c83-ac20-a0df41c805cc@redhat.com> Date: Thu, 13 Jan 2022 12:22:09 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader) To: Florian Weimer , Florian Weimer via Libc-alpha Cc: Andreas Schwab 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> <87y2497rp5.fsf@oldenburg.str.redhat.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <87y2497rp5.fsf@oldenburg.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, NICE_REPLY_A, 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: Thu, 13 Jan 2022 17:22:16 -0000 On 12/24/21 14:01, Florian Weimer via Libc-alpha wrote: > * 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. Agreed. The point is to have the same GLIBC_2.34 in ld.so and libc.so.6 to facilitate moving symbols in the future without needing to use a new version node. This makes complete sense. -- Cheers, Carlos.