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

[Michael Matz <matz@suse.de>]

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).

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.

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.


Ciao,
Michael.