Re: [PATCH 1/3] x86: Initialize CPU info via IFUNC relocation [BZ 26203]

[Florian Weimer <fweimer@redhat.com>]

* H. J. Lu:

> On Fri, Sep 18, 2020 at 6:59 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu:
>>
>> > On Fri, Sep 18, 2020 at 1:06 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >>
>> >> * H. J. Lu via Libc-alpha:
>> >>
>> >> > X86 CPU features in ld.so are initialized by init_cpu_features, which is
>> >> > invoked by DL_PLATFORM_INIT from _dl_sysdep_start.  But when ld.so is
>> >> > loaded by static executable, DL_PLATFORM_INIT is never called.
>> >>
>> >> I don't think that's accurate.  It's called from elf/dl-support.c in the
>> >> static case.  But I agree that it's too late in this case.
>> >
>> > I was referring to the ld.so case.  elf/dl-support.c isn't used for ld.so.
>>
>> I missed that.
>>
>> You cannot use ld.so in a static executable because it is
>> uninitialized/dormant.
>>
>> If you need functionality after static dlopen, it has to reside in
>> libc.so.6, not the dynamic loader.
>
> Here is the problem.  static dlopen uses libc.so.6 which brings in ld.so
> with _rtld_global and _rtld_global_ro via DT_NEEDED.  My patch is
> trying to deal with it to initialize CPU info in _rtld_global_ro in this case.

Putting this data into _rtld_global_ro is not correct if it is required
after static dlopen.  The current static dlopen approach simply does not
support that.  You can only assume that libc.so has been initialized
after static dlopen.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill