Re: dlsym(handle) may search in unrelated libraries

[Rich Felker <dalias@libc.org>]

On Thu, Feb 07, 2019 at 09:31:38PM +0100, Markus Wichmann wrote:
> > Yes, but you can also avoid recursion just by looping to the deepest
> > dependency with !inited, then going back to the root. For a one-time
> > operation at dlopen-time or program-start time, the quadratic search
> > for each !inited seems unlikely to be a problem:
> > 
> 
> Wait, I have an idea. If the only ordering is that the dependencies need
> to be initialized before their dependents, then couldn't we just
> initialize the libs in reverse BFS order? The elements further down the
> tree are all necessarily further down the list, aren't they?

No. Suppose X depends on Y and Z, and Z also depends on Y. If you do
reverse-BFS order, you'll construct Z before Y, despite Z depending on
Y (and Z's ctors depending on Y's ctors already having run).

> > I don't follow. The dlopen operation is not committed until load of
> > all dependencies completes successfully, and if any fail to load, the
> > whole operation is backed-out. But ctors don't/can't run until *after*
> > that, when we've already committed to success.
> 
> That is true for the runtime case, i.e. dlopen(). But load_deps() is
> also called at load time. And initializers have to run at load time,
> too. And in the correct order.
> 
> If at load time, any dependencies fail to load, an error message is
> printed and then the loop continues. load_deps() has no way to signal
> failure to the caller, and at load time it will not exit the function in
> another way, i.e. longjump (which is good since that would be invalid at
> that time). So by the time the initializers are called, all dependencies
> are loaded except those which failed.

See the definition of error(). It sets ldso_fail so that execution
never proceeds to the program.

Rich