This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Support -z initfirst for multiple shared libraries
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Yury Gribov <y dot gribov at samsung dot com>, d wk <dwksrc at gmail dot com>
- Cc: <nd at arm dot com>, <libc-alpha at sourceware dot org>, Jakub Jelinek <jakub at redhat dot com>, Kostya Serebryany <kcc at google dot com>
- Date: Thu, 28 Apr 2016 16:54:35 +0100
- Subject: Re: [PATCH] Support -z initfirst for multiple shared libraries
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <CAPESumqMqVem6VvaKXf_ko1zpM9_wOXixp1O7WGtS0RnvhMSpg at mail dot gmail dot com> <57206430 dot 9020206 at samsung dot com> <CAPESumqycYdiReUCUH51aLChaRLaTiGh121joQ_6rH7oRP+LAQ at mail dot gmail dot com> <5720F56E dot 6070704 at samsung dot com> <57222BEC dot 6080309 at redhat dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
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?
> 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.)