Why does dynamic linker search global scope before local scope?

Florian Weimer fweimer@redhat.com
Sun Jun 27 14:44:26 GMT 2021


* 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



More information about the Libc-help mailing list