On Thu 3. Oct 2019 at 9.12, Philip Guenther <guent...@openbsd.org> wrote:
> CVSROOT: /cvs > Module name: src > Changes by: guent...@cvs.openbsd.org 2019/10/03 00:10:54 > > Modified files: > libexec/ld.so : dlfcn.c library_subr.c loader.c resolve.c > resolve.h > > Log message: > Use a better algorithm for calculating the grpsym library order. > The existing code did a full recursive walk for O(horrible). Instead, > keep a single list of nodes plus the index of the first node whose > children haven't been scanned; lookup until that index catches the > end, appending the unscanned children of the node at the index. This > also makes the grpsym list order match that calculated by FreeBSD and > glibc in dependency trees with inconsistent ordering of dependent libs. > > To make this easier and more cache friendly, convert grpsym_list > to a vector: the size is bounded by the number of objects currently > loaded. > > Other, related fixes: > * increment the grpsym generation number _after_ pushing the loading > object onto its grpsym list, to avoid double counting it > * increment the grpsym generation number when building the grpsym list > for an already loaded object that's being dlopen()ed, to avoid > incomplete grpsym lists > * use a more accurate test of whether an object already has a grpsym list > > Prompted by a diff from Nathanael Rensen (nathanael (at) > list.polymorpheus.com) > that pointed to _dl_cache_grpsym_list() as a performance bottleneck. > > Much proding from robert@, sthen@, aja@, jca@ > no problem reports after being in snaps > ok mpi@ > Hi, out of curiosity, do you have any numbers to share? Thanks in advance, Ville
