From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10778 invoked by alias); 23 Feb 2016 15:44:42 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 10700 invoked by uid 89); 23 Feb 2016 15:44:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:single, sk:single-, Hx-languages-length:2788, und X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: port70.net Date: Fri, 01 Jan 2016 00:00:00 -0000 From: Szabolcs Nagy To: Michael Matz Cc: "H.J. Lu" , Alan Modra , gnu-gabi@sourceware.org Subject: Re: Specify how undefined weak symbol should be resolved in executable Message-ID: <20160223154437.GA29662@port70.net> References: <20160223044029.GE10657@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-q1/txt/msg00019.txt.bz2 * Michael Matz [2016-02-23 16:16:15 +0100]: > On Tue, 23 Feb 2016, H.J. Lu wrote: > > I checked cc1plus and found: > > > > [hjl@gnu-6 5.3.1]$ readelf -sW cc1plus| grep WEAK | grep UND > > Careful, that includes .symtab, not only .dynsym. These are the .dynsyms: > > > 33: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@GLIBC_2.3.2 (3) > > 2924: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_broadcast@GLIBC_2.3.2 (3) > > 4861: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_create > > 6330: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_getspecific > > 7205: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_unlock@GLIBC_2.2.5 (2) > > 7719: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_key_delete > > 9118: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __pthread_key_create > > 11985: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses > > 12269: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_once > > 15201: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock@GLIBC_2.2.5 (2) > > 15794: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_wait@GLIBC_2.3.2 (3) > > 18312: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable > > 19108: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_setspecific > > 19649: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__ > > 19871: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable > > 20107: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_destroy@GLIBC_2.3.2 (3) > > After here it's .symtab: > > > 18570: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_cond_signal@@GLIBC_2.3.2 > > > > Do you know how many of them lead to DT_TEXTREL? > > I think all those not going via the PLT, hence looking at the relocs for > those symbols involved, ignoring JUMP_SLOT relocs will give you that. For > my cc1plus it's only this: > > pthread_cancel > > (of those that are undef-weak), and only one reference. > libgcc/gthr-posix.h checks 'multi-threadedness' by looking at a weakref (if it's zero then single-threaded execution is assumed). on glibc the weakref is __pthread_key_create nowadays, but on other systems or older libgcc it's pthread_cancel. so the address of this weakref is taken, the other pthread weakrefs are called only if this weakref was non-zero. i'm not sure how the proposed changes affect this use-case, but this way of deciding single-threadedness is broken and a bug that gcc should eventually fix. (e.g. a static linked multi-threaded c++ application may not have a pthread_cancel symbol defined and thus libstdc++ may not use locks where necessary or crash when pthread_cancel is defined but other weakrefs are not).