From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47303 invoked by alias); 28 Nov 2019 18:48:24 -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 47274 invoked by uid 89); 28 Nov 2019 18:48:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=deemed X-HELO: albireo.enyo.de From: Florian Weimer To: Joseph Myers Cc: , Christian Brauner Subject: Re: [pushed] Block signals during the initial part of dlopen References: <20191127203048.27C2028173@gnutoolchain-gerrit.osci.io> Date: Thu, 28 Nov 2019 18:48:00 -0000 In-Reply-To: (Joseph Myers's message of "Thu, 28 Nov 2019 18:04:07 +0000") Message-ID: <87y2vz7s7j.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-11/txt/msg00997.txt.bz2 * Joseph Myers: > 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 I failed to test the later commits using build-many-glibcs.py because I deemed them more straightforward. The patch below should fix it. 8<------------------------------------------------------------------8< hurd: Add stub implementation of __sigprocmask to the dynamic loader The actual __sigprocmask cannot be built for the loader since it depends on per-thread state. diff --git a/sysdeps/mach/hurd/Versions b/sysdeps/mach/hurd/Versions index f69d5fef67..57d45e6d0d 100644 --- a/sysdeps/mach/hurd/Versions +++ b/sysdeps/mach/hurd/Versions @@ -41,6 +41,6 @@ ld { # functions that must be shared with libc __access_noerrno; __libc_read; __libc_write; __libc_lseek64; - __libc_lock_self0; + __libc_lock_self0; __sigprocmask; } } diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c index 719d603f44..e35ce69c4a 100644 --- a/sysdeps/mach/hurd/dl-sysdep.c +++ b/sysdeps/mach/hurd/dl-sysdep.c @@ -693,6 +693,15 @@ _hurd_intr_rpc_mach_msg (mach_msg_header_t *msg, timeout, notify); } +/* This function does nothing and will be interposed with the actual + implementation once is libc is loaded. Before that, manipulating + the signal mask does not make sense because no signal handlers have + been installed. */ +int weak_function +__sigprocmask (int how, const sigset_t *set, sigset_t *oset) +{ + return 0; +} void _dl_show_auxv (void)