Re: RFC: Add DT_FLAGS_2 and DF_2_GNU_IFUNC

[Carlos O'Donell <carlos at redhat dot com>]

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.

Cheers,
Carlos.