From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24776 invoked by alias); 28 Nov 2019 18:04:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 24768 invoked by uid 89); 28 Nov 2019 18:04:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: esa3.mentor.iphmx.com IronPort-SDR: SjmXEHDPtuC08K1VkNciPazYoJZrLZto9ObtvnWZMDHS5gKvgQXt2XukOP5L1DmwnH/O9S4zdA 5zIUpXQ/mfqXgzh/PC+7iWclvzeBMzLFfQ3U94drxlqlsyX4YCO9dcMWiohWPMy3mWHSxgllHt aEzLYIEHHLyhxaXw1oyYjbCfmgI9RGKo3nq+CDqQAjamjns/aCas5Ru6CKL8hfgZBNESJ1zy5U suZf/+NfJxkJX+QoAmdISbv3bEZuDw1ONkue9e4LiftoHKfgojUvSOyHi1HMG+ikzbWo4PUNOi kQo= IronPort-SDR: jPcTShtVaErRXoGNLOCLFD3/v7UWQXmyqCYaKqInEjQQh3xQlc7ntl8scQQCsq71Q0P4zN28Bp /2pZscIMFckPshyDU+RchrKn8so9c4mFES7s99uSSfGlA8o+S8zEFWniNkQBCq+3aOvWmTWwGf nJLckRYjRW9qbCAviLN/EJgk50oMwuJbT+nSLrYYnRvbGhGNX/A2unHU2sm7jh3tSejhyXI60h g0VorB8h+CiuMG25s3BSQPI4eInnCagLdZf+jc3MbHfHAtHTUw4IwW7wXTNUNr2v1kGFcxiuFi +UA= Date: Thu, 28 Nov 2019 18:04:00 -0000 From: Joseph Myers To: Florian Weimer , , Christian Brauner Subject: Re: [pushed] Block signals during the initial part of dlopen In-Reply-To: <20191127203048.27C2028173@gnutoolchain-gerrit.osci.io> Message-ID: References: <20191127203048.27C2028173@gnutoolchain-gerrit.osci.io> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-11/txt/msg00993.txt.bz2 On Wed, 27 Nov 2019, Sourceware to Gerrit sync (Code Review) wrote: > Block signals during the initial part of dlopen > > Lazy binding in a signal handler that interrupts a dlopen sees > intermediate dynamic linker state. This has likely been always > unsafe, but with the new pending NODELETE state, this is clearly > incorrect. Other threads are excluded via the loader lock, but the > current thread is not. Blocking signals until right before ELF > constructors run is the safe thing to do. This change (commit a2e8aa0d9ea648068d8be52dd7b15f1b6a008e23) breaks the build for i686-gnu (unfortunately this was after a syntax error was introduced in build-many-glibcs.py so my bots quietly died on re-execing with the syntax error, and so didn't get to find this build failure). There are a series of errors linking ld.so starting with: /scratch/jmyers/glibc/many9/install/compilers/i686-gnu/lib/gcc/i686-glibc-gnu/9.2.1/../../../../i686-glibc-gnu/bin/ld: /scratch/jmyers/glibc/many9/build/glibcs/i686-gnu/glibc/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal': /scratch/jmyers/glibc/many9/src/glibc/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__libc_fatal'; /scratch/jmyers/glibc/many9/build/glibcs/i686-gnu/glibc/elf/dl-allobjs.os:/scratch/jmyers/glibc/many9/src/glibc/elf/dl-minimal.c:188: first defined here and leading up to: make[3]: *** [/scratch/jmyers/glibc/many9/build/glibcs/i686-gnu/glibc/elf/librtld.map] Error 1 -- Joseph S. Myers joseph@codesourcery.com