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 ESMTP id F3AE93839C4B for ; Thu, 6 May 2021 09:17:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F3AE93839C4B 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-11-fjzw3fDCNgm9D4H_5wIG2w-1; Thu, 06 May 2021 05:17:29 -0400 X-MC-Unique: fjzw3fDCNgm9D4H_5wIG2w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA7431898298; Thu, 6 May 2021 09:17:28 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-137.ams2.redhat.com [10.36.112.137]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A6A5B19C9B; Thu, 6 May 2021 09:17:27 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: Andreas Schwab , GNU C Library Subject: Re: [PATCH v2] elf: Implement filtering of symbols historically defined in libpthread References: <87eeelfg77.fsf@oldenburg.str.redhat.com> <87h7jhxasp.fsf@igel.home> <877dkdate3.fsf@oldenburg.str.redhat.com> Date: Thu, 06 May 2021 11:17:45 +0200 In-Reply-To: (H. J. Lu's message of "Wed, 5 May 2021 13:53:46 -0700") Message-ID: <87zgx8i5l2.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.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.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_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 06 May 2021 09:17:33 -0000 * H. J. Lu: > On Wed, May 5, 2021 at 1:48 PM H.J. Lu wrote: >> >> On Wed, May 5, 2021 at 1:17 PM Florian Weimer via Libc-alpha >> wrote: >> > >> > * Andreas Schwab: >> > >> > > When bison is rebuilt with a linker that contains binutils commit >> > > b293661219c, it no longer crashes, and this patch isn't needed. >> > >> > Hmm. I worry we need to preserve compatibility with old binaries. No= t >> > everyone can do distribution bootstrap or has the source code to carry >> > it out. >> >> We never guarantee that applications linked against the old unversion >> glibc work with the versioned glibc today. Otherwise, we don't need >> glibc version at all. > > We can hide symbols for undefined, weak, unversioned references > from the old versioned binaries. If it's okay to deliberately break backwards compatibility with some old binaries, wouldn't we not use a patch at all? That's drop this patch and just use what's currently in the tree? I'm not sure which group of old binaries is more important (deliberate use of unversioned weak symbols in recent times vs binaries linked against glibc 2.0 using the accidentally). If it's okay to break things, I'm leaning towards =E2=80=9Cno patch=E2=80=9D (despite having spen= t quite some time on it). I may have to come back to this topic in a year or so, based on end user feedback. Given that the symbol filter does not have ABI impact, it's a backportable change, so I'm not too concerned to get this right immediately. Thanks, Florian