Why does dynamic linker search global scope before local scope?

Why does dynamic linker search global scope before local scope?

[Fengkai Sun]

Hi list,

After reading some LD_DEBUG messages, I've found that the dynamic linker
searches the global scope before the local scope, and the flag
RTLD_DEEPBIND can change this behavior.

I'm really curious about the reason why the dynamic linker won't search the
local scope first by default. To me, the static linker finds out the
dependencies of a DSO, and there is a very high probability that they are
defined in one of the DT_NEEDED entries. One can use the symbols in the
global scope to do interposition, but that is quite rare, so always
searching in the global scope seems tedious.

Currently, LD_PRELOAD is in the global scope, after the main executable.
Though the use of RTLD_DEEPBIND may invalidate the preload semantics, it's
just a design choice. The dynamic linker can search local scope first, and
add LD_PRELOAD somewhere in the local scope.

So I'm wondering why the dynamic linker is designed like this in the first
place.

Thanks for your time.


Best
Fengkai

Re: Why does dynamic linker search global scope before local scope?

[Florian Weimer]

* Fengkai Sun via Libc-help:

> After reading some LD_DEBUG messages, I've found that the dynamic linker
> searches the global scope before the local scope, and the flag
> RTLD_DEEPBIND can change this behavior.
>
> I'm really curious about the reason why the dynamic linker won't search the
> local scope first by default. To me, the static linker finds out the
> dependencies of a DSO, and there is a very high probability that they are
> defined in one of the DT_NEEDED entries. One can use the symbols in the
> global scope to do interposition, but that is quite rare, so always
> searching in the global scope seems tedious.

Interposing symbols from the main program is fairly common.  malloc is
the most obvious example, but this also happens with certain plugin
frameworks where the framework is available as both an executable (with
the framework statically linked) and a shared object.  In the latter
case, some shared objects may link against the framework dynamically,
but if running under the executable, the definitions in the executable
must be used.  Such an approach used to be quite common before the
effects of cheap PC-relative addressing, LTO and lack of semantic
interposition of locally-defined symbols were more widely understood.

> Currently, LD_PRELOAD is in the global scope, after the main executable.
> Though the use of RTLD_DEEPBIND may invalidate the preload semantics, it's
> just a design choice. The dynamic linker can search local scope first, and
> add LD_PRELOAD somewhere in the local scope.

Interposition does not necessarily involve LD_PRELOAD.

Thanks,
Florian