Re: RFC: Add DT_FLAGS_2 and DF_2_GNU_IFUNC

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

On Mon, May 28, 2018 at 9:52 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 05/25/2018 01:47 PM, H.J. Lu wrote:
>> As shown in
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=20019
>>
>> it is possible to create a shared object which references an IFUNC
>> function defined in another shared object.
>
> Which is not allowed in the present documentation:
> https://sourceware.org/glibc/wiki/GNU_IFUNC
>
> The GCC documentation says that resolver and implementation should be
> in the same translation unit.
>
> My opinion is that we need a *clearer* description of GNU IFUNC before
> we move forward with further kludges like this to make singular use
> cases work.
>
> At present your CPU dispatching library with LD_PRELOAD is treading
> on undocumented or poorly documented behaviour.
>
>> With non-lazy binding at
>> run-time, usage of such a shared object can lead to segfault.  The
>> issue is the shared object, which provides the IFUNC function, isn't
>> in DT_NEEDED and dynamic linker tries to resolve the reference to the
>> IFUNC function defined in the unrelocated shared object with non-lazy
>> binding.  Currently, the glibc dynamic linker issues a warning:
>
> The usage of GNU IFUNC is a runtime transformation by the dyanmic loader
> in much the same way as the static linker.
>
> If the usage of GNU IFUNC creates, at runtime, an additional startup ordering
> requirement on a specific shared object, then you have one of a few choices:
>
> * ... the shared object must list the superset of additional requirements
>   for all possible resolutions of GNU IFUNC.
>   - Burden on the user.
>
> * ... the dynamic loader must have enough information to compute the ordering,
>   possibly from relocations.
>   - Burden on the dynamic loader.
>
> * ... the dynamic linker can relax the IFUNC resolution until later.
>   - Already pointed out that relaxing BIND_NOW is unacceptable, unless it's
>     scheduled until later (like Florian's scheduling patch) without deferral.
>
>> [hjl@gnu-cfl-1 pr20019]$ ./main-dynamic
>> ./main-dynamic: Relink `./libbar.so' with `/export/build/gnu/glibc/build-x86_64-linux/libc.so.6' for IFUNC symbol `memmove'
>> Segmentation fault
>> [hjl@gnu-cfl-1 pr20019]$
>>
>> But it doesn't prevent segfault.
>
> Correct.
>
>> This patch extends gABI with DT_FLAGS_2 and DF_2_GNU_IFUNC to indicate
>> that a shared object or executable has IFUNC symbols so that dynamic
>> linker can relocate it early.
>
> I would like to see a very clear description of how this impacts GNU IFUNC's
> as feature design, and why it's the right solution.

I withdrew this.

-- 
H.J.