From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.51]) by sourceware.org (Postfix) with ESMTPS id 0CC6F3945C26; Thu, 29 Apr 2021 15:15:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0CC6F3945C26 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=bruno@clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1619709326; cv=none; d=strato.com; s=strato-dkim-0002; b=DX+h9q9IwFsi9BQ4IlDFgytOVB13krPdzW2B7N7dmOT8pOm58YOQLkyWBPonWFaS4W 29JYuXjES16uNZnLr+h88ohhrGT/Y6A8sc0ftAenaSCiyXye9VpCbiwLyIB+WVkURm+e 2IuP4uS18/8AYVXTO3PoEi5JkBRLkd2aYaqxnFSfy2D01XUseNaqKUf5sXUMcjUf7dHu Z4j5Py+xOLLSkuLrDXZYWTchJ8NQtnGaQvg9JJ+P0a3s6yguYo403FFPYUuIAtzBp4kR jXUv7fQpKNO14Uwi+SkEk17xb9StmOWa8VLsdNKIyLER2hf/tJ/Lk/QMALyxKiHOO4bz lhxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1619709326; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=j/Y2oVT9juf7aSSPA8hJd8Ja3qWVymlXPzq73sBdeOA=; b=Qi+IIKOJbTvQTBUmmZp3pZnTeilMg4ugwSPNhD5gvDVT7hPh8EqwvTAPIVs8s5Hecl 3Zj7j6y5aLVYGGkSpxPoSlBSGzWyENGspoFvpk0Y4rHmJ+4OAj6WQXFCe8cajMyELOTk Stw/7DMVbFOmJd0yJlWyr7uo/Kqrt+k8VcKwaRCZ//j4Qe13e2V+z5Q31RmQ7EAELeF4 9xeonSnSOMwvRrF2Is8gi8WNCRzhvCHjFCIgg+nA1Conv4gMCTCGzHq/sAt8CkiVmvO9 7CFz7vpy4QNDG0L5Gf3AjnNTjrfSGIhO00Vf9Agr6e/p72d4KaCC6kdu45Ly9dxFGCsW nExw== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1619709326; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=j/Y2oVT9juf7aSSPA8hJd8Ja3qWVymlXPzq73sBdeOA=; b=Mq3uv9oQrXC1dWyCA98zsDEmJgttY1FtqMvhHdmQBtFmslyL9DpT0VtUvyUtZqKUWY I7PPTKgr/5mARhLvPASfx48AthW1uPIp4GzTIgxdIi1Qt6wNSz3uzFDBcFf4vVKe+wXa ycDXRZHkgVbTGwaJmg502gjaMSmfH9mpj3FL5D2BJqqsvYLYIDiMnNEQ1X1FZTvqxPgd lAm6T/vPh6aYfA+DFPlOqVcQVVB91/WEJCQq/HqkdHtm1gIkw//msoPUUkAZzKCAKxxR aWKKpqDCgZ87YsgCnQbIRWG7G7vBxU6pU2z27zCyx5mT7sC8/T1sUkwNpGi0JvNgBXVo B82g== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf3z5NW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.25.2 DYNA|AUTH) with ESMTPSA id 905ad3x3TFFOEYO (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Thu, 29 Apr 2021 17:15:24 +0200 (CEST) From: Bruno Haible To: Florian Weimer Cc: bug-gnulib@gnu.org, libc-alpha@sourceware.org, binutils@sourceware.org Subject: Re: Undefined use of weak symbols in gnulib Date: Thu, 29 Apr 2021 17:15:23 +0200 Message-ID: <1745276.bs2KPpY2O9@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <87sg3agv90.fsf@oldenburg.str.redhat.com> References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <2800926.834q8TerIH@omega> <87sg3agv90.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, 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, 29 Apr 2021 15:15:30 -0000 Hi Florian, > > So, in the normal cases (link with '-lpthread', link without '-lpthread= ', > > and even with dlopen()), everything will work fine. The only problematic > > case thus is the the use of LD_PRELOAD. Right? >=20 > LD_PRELOAD and glibc 2.34 as originally planned. > ... > > In other words, the problem is that > > - there are some/many binaries out there, that were produced by an 'l= d' > > that did not anticipate the changes in glibc 2.34, and > > - these binaries have a problem not when run directly, but only when > > run with LD_PRELOAD. > > > > Right? >=20 > No, glibc 2.34 won't need LD_PRELOAD to expose the bug. LD_PRELOAD is > just a development aid that reveals the problem with glibc 2.33 and > earlier. Ouch, then it means that a significant number of binaries out there will crash when the system's libc is upgraded to 2.34. Many programs use "#pragma weak ..." in the way it was advertised 20 years ago. In fact, it was advertised to be useful for backward compatibility [1]= =E2=80=94 and now we face a problem with it, precisely regarding backward compatibili= ty. Here are just some occurrences of "#pragma weak pthread_*": =2D Gnulib - embedded in many GNU programs. [2] =2D GCC / libstdc++ - gthr-posix.[hc] (gcc-4.6.4) =2D libxml2 [3] =2D prelude-siem [4] > I spent today on coming up with a workaround in glibc. These are the workarounds I can see: - Delay the planned changes in glibc by 5 years or so, to minimize the number of binaries out there that would crash. (Probably not what you want.) - Change glibc's ld.so to deal with the binaries that are out there and that have been produced by existing binutils (with or without the patches that H.J. Lu listed). - Play tricks with the preprocessor, such as '#define pthread_create pthread_create_in_libc'. (Probably not POSIX compliant.) - Make use of symbol versioning. Symbol versioning was invented to allow making big changes to libc without breaking binary backward compatibility. (I don't know about the interplay between weak and versioned symbols.) > >> No, it's unrelated. The crash or other undefined behavior is a > >> consequence of actions of the link editor and cannot be reverted at run > >> time. I fear that you will need to touch the dynamic linker. The binaries that could crash are out in the wild. > However, you should really remove those weak symbol > hacks. They won't have any effect for glibc 2.34, and as explained Yes, I will remove them from gnulib, when a glibc >=3D 2.34 is found, simply to reduce complexity on glibc systems. But it will not help fixing the crashes when glibc 2.34 is released, because it takes time until 1. the gnulib changes are integrated into the packages that use gnulib, 2. these packages have had a tarball release on ftp.gnu.org, 3. users have replaced their old self-compiled binaries with newer ones. I am talking about a time frame from 3 to 10 years here. Bruno [1] https://en.wikipedia.org/wiki/Weak_symbol#Use_cases [2] https://git.savannah.gnu.org/gitweb/?p=3Dgnulib.git;a=3Dblob;f=3Dlib/gl= thread/lock.h;h=3Da0b24b63224cf44f862bd8e181e79b037c969d58;hb=3DHEAD#l242 [3] https://gitlab.gnome.org/GNOME/libxml2/-/blob/master/threads.c#L50 [4] https://www.prelude-siem.org/attachments/download/119/pthread-weak.diff