|
|
Flag day: Direct Bindings Enabled Throughout OSNet
Date: Thu, 24 Jan 2008 16:44:59 -0800
From: Rod Evans <Rod.Evans at sun dot com>
To: onnv-gate at onnv dot eng dot sun dot com, on-all at sun dot com
Subject: Flag day: Direct Bindings Enabled Throughout OSNet
Seems like this week is flag-day week! But, this is mostly a
"informational heads-up" rather than "you need to do something".
Famous last words.
-----------------
The putback of 4947191: "OSNet should use direct bindings" is the latest
integration in a long family of integrations that have allowed "Direct
Bindings" to be enabled throughout the OSNet.
Details of this binding technique can be found in the "Direct Bindings"
Appendix of the SDX version of the Linker and Libraries Manual:
http://docs.sun.com/app/docs/doc/819-0690/aehzq?a=view
or
http://linkers.central/llm/p50.html
There are no major tool synchronization requirements associated with
this integration, and in theory, all OSNet utilities should continue to
run as they always have. At least, that's what the previous family of
integrations have tried to achieve.
To ensure that direct bindings remain in use throughout the OSNet,
check_rtime(1) has been updated to verify that all OSNet dynamic
objects use direct bindings. If you do see a check_rtime message like:
foo: object has no direct bindings <no -B direct or -z direct?>
then you are using a new check_rtime against an environment that is
pre-4947191 integration, or components within your environment have
not triggered an incremental build after bringing over the 4947191
changes, or you have a new component that isn't inheriting the correct
Makefile.cmd/lib flags that enable direct binding.
-----------------
Direct Bindings is an alternative model for the runtime binding of
dynamic objects. The original runtime binding model has served us
well for 20+ years, due to its power and simplicity. However, this
model was conceived in an era when most dynamic applications used one
or two dynamic dependencies. This model has become more difficult to
manage today, in an era when some applications are built from dozens of
sharable objects. Direct bindings give us additional tools for managing
such large applications.
The only concern developers typically need have with this technology
is its interaction with interposition. The bulk of enabling integrations
that have come before 4947191 have revolved around interposition
requirements, and ensuring that those OSNet components that expect to
interpose on symbols, continue to do so.
However, if you control external applications that expect to interpose
on OSNet interfaces, this integration may disrupt your application, and
you should read on.
-----------------
Interposition - you either love it, or you hate it. The traditional
runtime symbol binding model has the runtime linker (ld.so.1(1)) search
for symbols starting at the application (main) and inspecting each
dependency, in the order the dependencies were loaded, until the symbol
is found. If multiple symbols of the same name exist in different objects,
the first object that offers the symbol is bound to. This symbol is
said to interpose on others of the same name.
Developers have used this technique to provide alternative implementations
of known interfaces, and thus alter the normal functionality of a program.
This system is very simple, and very powerful. However, with so many
dependencies and symbols in todays processes, unintentional interposition
is occurring more often, not because the developer redesigned an existing
interface, but because they accidentally chose a name that clashes with
an existing interface. Sadly, most user dependencies expose a lot of
internal symbols that should be hidden via scope reduction, and these
exposed symbols make matters worse.
In addition, applications now exist that are comprised of objects that
desire to bind to different implementations of an interface that has
the same name.
Direct bindings offers a different binding model. At link-edit time
an association is recorded between an object that makes a symbol
reference, and the object that provided that definition at link-edit
time. In a nutshell, if libfoo.so.1 calls printf(), then when this
library is built against -lc at link-edit time, the association between
libfoo and libc for printf() is created. At runtime, ld.so.1 will look
for libfoo's printf() reference "directly" in libc.so.1, without going
through the exhaustive search starting with the application.
Hence, direct binding protects against accidental interposition. But,
in reality, direct binding protects against all interposition. It does
this by requiring you to explicitly identify interposition, rather than
making interposition the default case. Most interposers are established
with LD_PRELOAD, and the use of this environment variable automatically
tags the preloaded objects as interposers. Other means of identifying
an interposer are with the link-editors -z interpose, or with individual
mapfile INTERPOSE definitions.
In addition, there are numerous mechanisms for preventing a direct binding
to a symbol, including the link-editors -Bnodirect, and the mapfile
NODIRECT definition. For example, the malloc() family have been
interposed upon by many applications. Therefore, these interfaces have
already been labeled as NODIRECT so that existing applications continue
to function without having to be explicitly identified as interposers.
Previous direct binding integrations have attempted to establish a
compromise between labeling commonly interposed upon interfaces as
NODIRECT, and identifying more specialized interposing applications
as explicit interposers.
For a full explanation of all these techniques see the "Direct Bindings"
Appendix of the SDX version of the Linker and Libraries Manual:
http://docs.sun.com/app/docs/doc/819-0690/aehzq?a=view
or
http://linkers.central/llm/p50.html
The components of the link-editors (sgs) have been directly bound for
some time now. A few OSNet libraries already employ direct bindings,
and a bunch of Gnome components have been directly bound also.
However, there are a lot of interesting applications out there, and
any that interpose on system libraries, that haven't yet been discovered,
may behave "differently" after this integration.
BTW, lari(1) can prove very useful in ferreting out multiply defined
symbols, and observing what process bindings actually occur.
Any issues or problems - contact me.
--
Rod.
|