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

[Alan Modra <amodra@gmail.com>]

On Mon, Feb 22, 2016 at 02:43:55PM -0800, H.J. Lu wrote:
> we create executable with dynamic R_X86_64_32 relocation against
> fun .text section, which leads to DT_TEXTREL.  Is this what we want?

I think that avoiding DT_TEXTREL is historically why we haven't
supported weak symbols well in non-PIC executables.  Another closely
related issue is the old hack written into most ABIs that the address
of a function referenced in an executable and defined in a shared
library is the address of that function's PLT code in the executable.

Note that this affects both defined and undefined weak functions in
non-PIC executables.  Currently, if we find a definition for "fun" at
link time in a shared library, "&fun" is the PLT entry in the
executable and "if (&fun)" effectively becomes "if (1)".  So if you
link the executable with a shared library containing a definition of
"fun" but at run-time load a newer shared library *not* defining "fun",
your program will segfault.

Therefore, if the aim is to make PIC and non-PIC executables behave
the same you need to change defined weak symbol behaviour too.  Any
non-PIC executable that takes the address of a weak function in code
or rodata would become DT_TEXTREL.

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.

-- 
Alan Modra
Australia Development Lab, IBM