Reducing library dependancies

[Maksim Orlovich]

> Yes, results attached. Command was:
>
> eu-readelf -r libkdeui.so | \
> 	awk '/386_(32|GLOB_DAT)/ {print $4}' | \
> 	uniq -c | \
> 	sort -n -r | \
> 	c++filt
>
> The number to the left is the number of times the symbol is used. There
> are
> 1551 distinct symbols in use, 936 of which are used only once, 261 twice,
> 91
> three times (or 1288 symbols for 1731 relocations).
>
> You will notice that the symbols most used are those required for the
> virtual
> tables. That means we have 244 non-trivial classes in kdeui, and at least
> 226
> of those derive ultimately from QObject.

Thanks for the numbers; however isn't multiplicity far less relevant these
days?
IIRC, the relocations are sorted to have duplicates adjacent, and ld.so
has a last-entry cache.  I am also getting different numbers with the
kubuntu build  here --- nearly 3000 distinct entries. The difference
appears to be due to various virtuals inside kdeui proper. Did you build
kdeui with -Bsymbolic or something? Still, 3000 isn't quite as bad as
10,000...

It does seem like there isn't much we can do on our end (there do seem to
be about 75 symbols from private classes leaking out, but that's certainly
not a huge fraction).
It seems that even w/o a new relocation type it should be possible to
avoid the in-library symbolic relocations to vtables and the like,
however. Out-of-library they would still be needed, of course.

> The only way to reduce this count is to convince the gcc and binutils
> people
> that a relocation type specific for virtual tables is a must.

This definitely does seem optimizable at that level, since slots in the
child vtable
can be merely copied from the parent one, so there isn't really need to do
symbolic resolution beyond the initial vtable symbol.  It does introduce a
recursive resolution dependency, however, but that symbol can be
determined statically, too.
(I am also not sure of things like ti-merging and single definition rule
with stuff emitted all over the place...).

[I suppose one can also override every single virtual with a forwarding
stub, which would result in a lazy PLT entry; I guess objprelink used to
do something similar?]


-Maks