Re: Specify how undefined weak symbol should be resolved in executable

[Szabolcs Nagy <nsz@port70.net>]

* Michael Matz <matz@suse.de> [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).