[PATCH] Support -z initfirst for multiple shared libraries

[Yury Gribov]

On 04/28/2016 06:54 PM, 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 was my expectation as well.

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