Re: Question re: dynamic linking in musl

[Alexander Monakov <amonakov@ispras.ru>]

On Wed, 27 May 2015, Alex Dowad wrote:
> I'm just dealing with a problem whereby rrdtool is spending >90% of its runtime in
> musl's dynamic linker (this is on Alpine Linux). This is making it too slow to do
> what we need it to do.

That implies that rrdtool spawns an executable with many dynamic dependencies
over and over again, with each individual invocation doing extremely little
work.  That sounds wasteful.  Do you know why it does that?

Can you confirm that the behavior is similarly bad on glibc with LD_BIND_NOW=1
set in the environment?  The main difference between musl and glibc is that
glibc perform "lazy binding" while musl fully resolves all symbol dependenies
at load time.

Can you also provide exact figures?  For example your callgrind logs?  Or just
'time' statistics for executables that spend much time in the dynamic linker.

> NOW: Is there any reason why dso->deps could not be used to search for symbols *only*
> in the dependencies of the binary which is currently being relocated?

That is not how ELF symbol lookup works.  Simply put, the symbol should be
taken from whatever first module in the whole lookup chain provides it; e.g.
if the executable exports a function that is also exported in libX11, the
executable's definition prevails.
 

Recently I was working on some dynamic linker speedups for musl.  On my
testcase, Clang/LLVM with ~100-200 dynamic libraries and ~20000 symbols that
need to be resolved in the dynamic linker, I obtained a speedup from 240 ms to
110 ms, while glibc needs 50 ms with lazy binding and 140 without.  So while
musl's dynamic linker speed can be improved, still rrdtool is doing something
odd in the first place if it's performance is bound like that.  I'd like to
understand that.  If it's unavoidable, perhaps static linking is appropriate.

(I didn't send my dynlink speedup patches yet;  I intend to do that sometime
soon)

Alexander