[Bug dynamic-link/14379] shared object constructors are called in the wrong order

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=14379

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Rich Felker from comment #9)
> I question the validity of this issue. Such a malloc implementation would
> not work linked into the main program, nor as a DT_NEEDED for the main
> program (assuming other libraries are in use with ctors), so there's no
> reason to expect it to work in the LD_PRELOAD case either.
> 
> If there is a desire to make this work, special-casing LD_PRELOAD is not the
> right way. Instead, when library A depends on library B, and library C
> interposes in front of a symbol defined in library B and used in library A,
> the ctor ordering should attempt to arrange for C's ctors to run before A's
> (and probably also before B's). I'm not sure if such a constraint is easy to
> satisfy in general though (for example, it wouldn't work in the main-program
> case above; you'd get a circular constraint), and I suspect it's a mistake
> to try.

This is an interesting point.  I think you are right that this reliance of ELF
constructors is always going to be brittle (especially for a malloc).  I'm less
convinced now that this feature is desirable, I'm afraid.

We actually record implicit dependencies during binding, and I believe this can
affect the order in which ELF finalizers are executed.

However, I'm not entirely sure if this behavior (whether implemented for ELF
constructors or destructors) would be consistent with the ELF specification. 
Furthermore, most users expect that finalizers run in the opposite order of
initializers, disregarding any bindings which happened in the meantime.  This
is so confusing that I've been contemplating if we should disregard the symbol
binding information for finalizer ordering purposes.

I'm also worried that accidental interposition is fairly common for widely used
C++ templates (e.g. std::vector<std::string>).  If I'm not mistaken,
interposition goes in the opposite detection of the DT_NEEDED dependencies, so
this would result in effectively reverting the order of initializers (objects
initialized before their dependencies).

-- 
You are receiving this mail because:
You are on the CC list for the bug.