[Talk] State of dynamic linking in various platforms...

[Chris Maltby]

> On 2002-Aug-22 14:50:32 +1000, Michael Paddon <michael at paddon.org> wrote:
> >Statically linked executables have several key advantages IMHO:
> >   * faster (no run time linking necessary, but who cares with an n GHZ
> >     processor)

On Thu, Aug 22, 2002 at 03:20:57PM +1000, Peter Jeremy wrote:
> Runtime linking generally implies PIC for the shared libraries - on
> most systems, this means you lose a register (it's needed to support
> PIC).  On the iA32, the loss of a register is a further performance
> hit (since there aren't many to start with).

That's mostly a compiler issue. I don't want to debate the strengths
and weaknesses of ia32, but there are ways to minimise the impact of
PIC.

> And as for speed, we have some applications that take 10 seconds of
> CPU time (on a fast Alpha) to start - courtesy of the runtime loader
> (and that's with lazy function binding, so the 10 seconds is just to
> bind variables).  We would love to be able to statically link them...

That'll be tru64 then, wouldn't it. Are you sure there aren't linker
options to speed up the binding? What about ld -msym... You can also
set the LD_BIND_NOW environment variable and put some logging args in
_RLD_ARGS to gather information. See loader(5) and ld(1).

> The "buy a faster processor and more disk space" approach leads to
> abominations like WinBloze.

True, but the change in relative speeds and sizes does make a difference.
When Solaris shared libraries first appeared there was a lot of debate
about the extra memory required to map all the bits of the library you
mightn't actually use, but as you add users/processes the sharing ratio
goes up and soon you are using less memory overall.

> >All that being said, I reckon that the memory efficiency issue trumps
> >all for system executables. Make everything dynamic.

> Actually, memory efficiency is generally higher for static executables.
> The rtld needs to scribble in the text segment to do address fixups
> so you lose most of the sharability gains.  Also, if you only have
> one application using a shared library, you wind up paying for the
> bloat of the complete .so, instead of just that bit that the application
> actually uses.

I haven't noticed anyone implementing dynamic binding by writing on
the code. Are you sure about the need for the rtld to do it, because it
doesn't fit with any system I'm familiar with. The usual approach is a
writable jump table, with each slot initialised to point to the dynamic
binder, which then replaces itself with a pointer to the actual call.

> >What about people who whine about recovery?

> If you're doing bleeding-edge development (eg FreeBSD-CURRENT),
> it's not that unheard pick a bad time to update and trash critical
> bits of your system.

kernel development has always demanded "crash and burn" partitions.
No-one serious runs their development kernels on their irreplacable
data...

> There are also security implications - with a dynamically linked
> executable, there can be a long chain of assorted libraries that
> you wind up executing - each of which need to be protected (along
> with all their parent inodes).  I think I once counted >20 inodes
> accessed for a dynamically linked "hello world" on Solaris.

There's always a way for someone to stuff it up.

I'm surprised that no-one has mentioned cache performance so far in
this thread. If everyone is sharing the same library, then it will
persist in the hardware caches and TLBs etc across context switches.
That can be a very big win with the big difference between CPU and
memory/bus speeds we see today.

Chris