On Thu, Feb 07, 2019 at 04:42:15PM +0300, Alexey Izbyshev wrote:
> I think the easiest way is simply to modify load_deps() to always traverse
> DT_NEEDED in breadth-first order without relying on the dso list in the
> outer loop. load_deps() already effectively maintains a queue (deps) that
> can be used for BFS, so no recursion is needed.

OK, since we have to implement a BFS, that does in fact work. So I
implemented that. Still needs testing, though.

One side effect is, patch 7 from the previous mail was reverted.

Another is that now load_deps() depends on the deps array as loop
structure. I was almost as far as just using the runtime code and adding
an a_crash() in case of allocation failure during loadtime, but then I
decided to just split loadtime and runtime apart. So
load_deps_loadtime() is just a copy of load_deps(), refactored with the
assumption runtime==0, and load_deps_runtime() is a copy of load_deps(),
with the patch discussed here and refactored under the assumption
runtime!=0.

I had noticed, during the refactoring, that this means that app->deps ==
{0}, always. So I wondered if that might bite us. However, the only
normal way to obtain a handle to the app itself is to call dlsym() with
RTLD_NEXT. Which is one of the special symbols that will load symbols
from the given DSO and all following ones in the symbol list. And all of
the main app's dependencies are immediately added to the symbol list
after the first load_deps() call (now load_deps_loadtime()).

For Rich's comfort, I am attaching patch 6 again, so all relevant
patches are in one mail.

> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html
> [2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlopen.html
> 

Right you are, again. Maybe I should read more POSIX before working on
these things. :-)

> Alexey
> 

Ciao,
Markus