Specify how undefined weak symbol should be resolved in executable

[Michael Matz]

Hi,

On Tue, 23 Feb 2016, H.J. Lu wrote:

> > Hmm, that's less than ideal of course.  Well, if the goal is to make 
> > PIC and non-PIC the same, we could also go the opposite way: make PIC 
> > behave like non-PIC, i.e. resolve weak symbols always at link editing 
> > time.  That of course would remove features (can't change libs at 
> > runtime anymore, if they change in definedness of such a symbol).
> 
> This "feature" never worked on x86 for non-PIC input.

True (and that's exactly the difference between PIC and non-PIC).

> If we change ld now, all of a sudden, x86 binaris are marked with 
> DT_TEXTREL.  What we can do is to add a new linker command option, -z 
> dynamic-undef-weak, and GCC passes it to ld only when compiler is 
> changed to generate PIC-like code for address of all undefined symbol in 
> text section.

Hmmnyeah, possible.

> > Note that the existence of DT_TEXTREL itself isn't that bad: only those
> > pages that actually contain relocations will be unshared, so for the
> > example of crtbegin.o it's only one page per process.  In addition
> > crtbegin could of course always be PIC code, avoiding the issue.
> >
> > I've looked at a normal c++ program (zypper) and the only weak undef
> > symbols are those from crtbegin.  There are many other weak symbols, but
> > they are defined in the executable itself (it's mostly template
> > instantiations), so pose no problem.
> >
> >
> 
> 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.


Ciao,
Michael.