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

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra <amodra@gmail.com> wrote:
> 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.
>

Not only we need to change defined weak symbol behavior, we
also need to change undefined non-weak symbol behavior when
taking its address.  We need to generate PIC-like code to take
address of a symbol in non-PIC text section.  Is this what we
want?


-- 
H.J.