Re: [PATCH 1/2][RFC] #17645, fix slow DSO sorting behavior in dynamic loader

[Chung-Lin Tang <chunglin_tang at mentor dot com>]

On 2019/7/29 5:48 PM, Florian Weimer wrote:
> * Chung-Lin Tang:

> > > Can your test framework test both cases?  What's your position on the
> > > second effect?  I think it sometimes results in destructors running not
> > > in the opposite order of constructors, due to the new topological sort.
> > > (This also happens with the current implementation.)
> >
> > What I did in the ld.so code patch was add a second pass of sorting
> > that ignores runtime deps, prioritizing link dependencies; this
> > appears to also be what prior discussion pointed towards, see more
> > details in that 2nd email with the actual code patch.
>
> I wonder if it makes sense to disentangle this (desirable) functional
> change from the rest (which sould be purely an optimization).

By "functional change" here, are you referring to the testing framework,
or the described ld.so destructor behavior I described above?

> Is it even necessary to re-sort on dlclose?  Is the original dependency
> order available somewhere?  Then we could make it explicit that the
> destructor order is the reverse of the constructor order (for the
> objects unloaded).  Or is there a corner case which causes an expected
> divergence?

Dynamic loaded objects could add more relocation dependencies, and thus augment
the dependency relations (by adding more constraints), so a final sort should
still be required.

Thanks,
Chung-Lin