[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Tue, Feb 23, 2016 at 5:55 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra <amodra@gmail.com> wrote:
>> >
>> > However, that might be a bad idea.  Lots of C++ code uses weak symbols
>> > for functions defined in header files, and other objects with vague
>> > linkage.  These result in weak definitions in eg. libstdc++.so.  I'm
>> > not sure how many executables take the address of such functions and
>> > thus might become DT_TEXTREL.
>>
>> Most, if not all, of programs will have DT_TEXTREL on x86 if undefined
>> weak symbols require dynamic relocations.
>
> 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.

> Or, a third variant: change the compiler to emit PIC like code for taking
> addresses of weak symbols also in generally non-PIC code, so we could
> avoid TEXTREL.
>
> I think the ideal solution would be that last one, change link editor now
> to behave like with PIC code, and eventually fix the compiler to not have
> to generate TEXTREL.

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.

> 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
    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)
 18570: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND
pthread_cond_signal@@GLIBC_2.3.2
 21461: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND
pthread_cond_broadcast@@GLIBC_2.3.2
 23398: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND pthread_key_create
 24867: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND pthread_getspecific
 25742: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND
pthread_mutex_unlock@@GLIBC_2.2.5
 26256: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND pthread_key_delete
 27655: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __pthread_key_create
 30521: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
 30805: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND pthread_once
 33737: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND
pthread_mutex_lock@@GLIBC_2.2.5
 34330: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND
pthread_cond_wait@@GLIBC_2.3.2
 36848: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
_ITM_deregisterTMCloneTable
 37644: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND pthread_setspecific
 38185: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
 38407: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
_ITM_registerTMCloneTable
 38643: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND
pthread_cond_destroy@@GLIBC_2.3.2
[hjl@gnu-6 5.3.1]$

Do you know how many of them lead to  DT_TEXTREL?

-- 
H.J.