Re: RFC: x86: Fall back to lazy binding for unrelocated IFUNC symbol [BZ #23240]

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

On Wed, Jun 6, 2018 at 8:53 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/06/2018 05:38 PM, H.J. Lu wrote:
>>
>> I pushed hjl/pr23240/fw, which is fw/bug21242 + tests for [BZ #23176] and
>> [BZ #23240].
>>
>> 1. On x86-64:
>>
>> FAIL: elf/reldep6a
>
>
> The crash happens because “weak” is undefined in reldep6mod1.so.
>
> The “weak” function is defined in reldep6mod4.so.  But reldep6mod1.so is
> loaded before reldep6mod4.so:
>
>      14289:     calling init:
> /home/fweimer/src/gnu/glibc/build/elf/reldep6mod1.so
> …
>      14289:     opening
> file=/home/fweimer/src/gnu/glibc/build/elf/reldep6mod4.so [0];
> direct_opencount=1
>      14289:
>      14289:     binding file
> /home/fweimer/src/gnu/glibc/build/elf/reldep6mod4.so [0] to
> /home/fweimer/src/gnu/glibc/build/elf/reldep6mod1.so [0]: normal symbol
> `baz'
>
> I think this is simply invalid.  I think that if you had a “weak == NULL”
> check in reldep6mod1.so, it would be false even after loading reldep6mod4.so
> because the address is not lazily bound.
>
> Is this derived from the X server use case, where they load additional DSOs

No idea.  It is in elf.

> which provide definitions of functions which are lazily bound? That's just
> not compatible with BIND_NOW, and I don't see a compelling reason why it
> should be.  If it's just about fixing X, then we need to fix X, and not
> enhance the dynamic linker.
>
>> 2. On i686:
>>
>> FAIL: elf/ifuncpreload1
>> FAIL: elf/reldep6a
>
>
> There's no delayed processing for i686 yet.  I wanted to get consensus on
> the overall approach first.
>
> Thanks,
> Florian



-- 
H.J.