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

[Florian Weimer <fweimer@redhat.com>]

* Chung-Lin Tang:

> On 2019/7/23 9:21 PM, Florian Weimer wrote:
>> Is => intended to cover the case of run-time dependencies added late due
>> to lazy binding?
>>
>> Currently, those late dependencies have two effects, I think: They keep
>> around the referenced libraries longer than before (so that dlclose
>> would not remove an object which is still in used solely due to lazy
>> binding).  And the ELF destructors are reordered to reflect these added
>> run-time dependencies.
>
> Yes, you can test that. The effect of => is to create a caller/callee
> relation between objects: 'x=>y' creates fn_x() and fn_y() in those
> two DSOs, and fn_x() has a call to fn_y().
>
> Though that's the only immediate effect that => has. To construct a
> test of run-time added dependencies related to dlopen/etc. you also
> need to add those operations inside the '{}' construct.
>
> All the created DSOs have a constructor/destructor that outputs their
> single character name. The generated main() program prints '[]'
> brackets after dlopen/dlclose calls to separate out the following
> constructor/destructor output.  So taken whole, the entire output
> string should capture all constructor/destructor activity and ordering
> behavior.

I see, thanks.

>> 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).

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?

Thanks,
Florian