Re: [PATCH] Support -z initfirst for multiple shared libraries

[Carlos O'Donell <carlos@redhat.com>]

On 04/28/2016 11:54 AM, Szabolcs Nagy wrote:
> On 28/04/16 16:27, Carlos O'Donell wrote:
>> On 04/27/2016 01:22 PM, Yury Gribov wrote:
>>> Yeah. It seems that initfirst is a crude hack which bypasses all
>>> dependency tracking. I wonder if there's a place for another,
>>> hopefully saner, dependency-respecting flag.
>>
>> What use cases do you need to support?
>>
>> How would a dependency-respecting initfirst-like flag work given the
>> conflicting requirements to initialize in dependency order and yet
>> not initialize in dependency order?
>>
> 
> may be use a topological sort order where the
> flagged module comes earliest possible?

That makes sense.

>> Today we have:
>>
>> - Library initializers and finalizers (Run in dep order)
>> - Library constructors and destructors (Run in dep order)
>> - Prioritized constructors and destructors (Run in dep order, and # order)
>> - LD_PRELOAD initializer run last before the application is initialized.
>> - Non-zero initialized data from .data in the ELF image.
>>
>> Dependency ordering also include symbol dependencies and relocation 
>> dependencies, sorting all objects into a linear list and breaking
> 
> if that was done correctly then i think LD_PRELOAD
> libs would come before the modules using the interposed
> symbols.

I *thought* this was what was implemented by _dl_lookup_symbol_x,
add_dependency, and link_map->l_reldeps, but after reviewing the code
and writing some test case it doesn't work for all use cases.

We have add_dependency which is called from _dl_lookup_symbol_x
which adds symbol binding information, but it isn't used properly
to sort constructors in the -Wl,-z,now case (you can't do this in
lazy mode).

For destructors though, in _dl_sort_fini, we do use l_reldeps to move
dependencies such that objects which are the target a symbol binding
are destructed later (if possible).

For dlclose we prevent unloading a shared library that is the target
of a bound symbol used by another shared library (see the common
problem with STB_GNU_UNIQUE making C++ plugins unloadable).

>> cycles where appropriate at deterministic points (though we need
>> a better ldd to show these problems).
>>
>> It might be better if we had some kind of invariant assertions like
>> "abort if I'm not initialized before library SONAME" that then allowed
>> developers to realize their invariant is wrong and restructure the
>> application. Alternatively if we had some better tooling that might
>> help also (I'm working on an alternate eu-ldd and deterministic
>> cycle breaking in ld.so, but it's a long way off).
>>
> 
> depending on elf ctor ordering sounds broken to me.
> (incompatible with static linking)

What we are talking about today is adding features to work around
existing design issues in applications.

Properly designed applications don't have these problems because they
don't rely on constructor ordering outside of a translation unit.

> depending on deterministic ordering in the presence
> of cycles sounds even more nonsensical.
> (the dynamic linker shouldn't try to solve np hard
> problems.)

Sorry, that's not what I wanted to imply.

All I wanted to say is that cycles should be broken following some
fixed set of rules that we can then test ourselves (without giving
users any guarantees) with regression tests, simply to validate
the dynamic loader is behaving as we expect.

I *do* think we need to provide a tool that shows users what the
ctor/dtor ordering is going to look like and why, for the given
installed loader. This could be used by support to diagnose problems
and remind users not to rely on ctor/dtor ordering.

-- 
Cheers,
Carlos.