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

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

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?

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
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).

-- 
Cheers,
Carlos.