[Bug dynamic-link/17645] RFE: Improve performance of dynamic loader for deeply nested DSO dependencies.

["paulo.cesar.pereira.de.andrade at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

Paulo Andrade <paulo.cesar.pereira.de.andrade at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #7972|0                           |1
        is obsolete|                            |

--- Comment #8 from Paulo Andrade <paulo.cesar.pereira.de.andrade at gmail dot com> ---
Created attachment 8193
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8193&action=edit
Proposed patch

Updated proposed patch, without ChangeLog entry,
just for asking for extra comments.

I understand this patch touches a too sensible
part of glibc, and the only reason I wrote it is
due to the test case, where the proposed patch
runs 5+ orders of magnitude faster, and appears to
be fully functional, when tested in fedora and
running very complex applications.

This is basically the same patch, but now it scans
the list in reverse order. This is is actually the
correct way to do it, so that on most common/simple
cases/cycles it outputs the same sorting as current
glibc.

But I would like to have one clarification, that maybe
is being already tested, and the Makefile patch to
have only one result is in fault.

tst-initorder is basically this:

a2 a1          # a2 is linked to a1
b2 b1 a2       # b2 is linked to b1 and a2
a3 b2 b1       # a3 is linked to b2 and b1
a4 a3          # a4 is linked to a3
main a4 a1 b2  # "main" is linked to a4, a1 and b2

this will cause the sort input like this:

[ main a2 a1 b2 b1 a3 a4 ]

My question is, is some documentation that says
that dsos must be kept together in the ordering?
I mean, there are 2 correct results:

main a4 a3 b2 b1 a2 a1

and

main a4 a3 b2 a2 a1 b1

but if there is some specification that says
it should have "b2 b1" together, then the patch
is invalid, because it only breaks cycles and
does ordering, and if there are no dependencies,
it keeps it in the order it received the list
to sort.

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