|
|
Heads up - a whole heap o' changes ...
Date: Thu, 17 May 2007 16:27:19 -0700
From: Rod Evans <Rod.Evans at sun dot com>
To: onnv-gate at onnv dot eng dot sun dot com
Subject: Heads up - a whole heap o' changes ...
The putback of:
6455532 OSNet cleanup required in preparation for direct bindings
is a heads-up for all userland developers.
This putback is a prelude to enabling direct bindings through out all
the OSNet dynamic objects (see 4947191). With direct bindings we
hope to avoid accidental interposition problems, allow objects to
bind to different versions of the same library, and reduce the
overall runtime symbol search cost of large dynamic processes.
Another project hopes to revisit the whole synonyms.h use within
the OSNet after direct bindings have been enabled.
A new chapter to the Linker and Libraries Guide has been created
that pulls together the concepts of direct binding. Many of the
implementation details have been available for a long time now, and
some subsystems have been employing direct bindings for a while.
This chapter finally attempts to put all the associated topics in
one place. You can find a copy of this chapter under "Direct
Bindings" in:
http://linkers.central/llm/toc.html
http://linkers.sfbay/llm/toc.html
There's also a pdf version of the "Direct Bindings" Chapter under:
http://www.opensolaris.org/os/community/tools/linker/
But, there's a gotcha. The largest benefit of direct bindings is that
they prevent accidental interposition, the all too common situation where
a symbol is found in the wrong library, due to variations in the order
in which libraries are loaded, or the evolution of name space pollution.
These unintentional bindings can be difficult to understand, and time
consuming to debug. However, the benefit of direct binding comes at a
price - intentional interposition has to be stated explicitly, otherwise
it can be circumvented by a direct binding. Explicitly defining an
interposition requirement is easy when code is being written, but can
be challenging to discover when an existing object is converted to
use direct binding, as the desired interposition may not be well
documented or obvious. Extensive investigation of the OSNet has found
lots of interposition. Some intentional, some odd, and some you have
to wonder how anything really works. lari(1) has been very useful in
investigating our interface usage.
For interposition to work within a directly bound environment, the
interposition requirement must be *explicitly* defined. And that,
is what this putback is really all about. All the interpositioning
requirements that are required with the OSNet have now been labeled
(ld -zinterpose, or mapfile INTERPOSE definitions). All interfaces
that must not be directly bound to have also been labeled
(ld -Bnodirect, or mapfile NODIRECT definitions). In addition, a
number of duplicate interfaces have been removed, either using
filtering techniques, or a new map.noexeglobs mapfile (more later).
This wad had been reviewed by a number of folks whose applications
have been modified, tested by some of the same folks, bfu'd to
various places, plus it's been through PIT, and it's been built
with Studio and gcc But, when you start mucking with interfaces like
this, there's a chance I missed something. So, if you experience
anything odd with symbol bindings following this putback, please
let me know.
A webrev of the changes is available:
http://linkers.central/webrev/6455532/
A couple of build changes are worth mentioning.
i. Our mapfiles used to be spread around the source base.
All commonly used mapfiles are now under usr/src/common.mapfiles.
ii. Some objects have been versioned so that they no longer
export any (or most of) their symbols. This was necessary
to guard against the potential for interposition against
incompatible interfaces of the same name.
This versioning uses the mapfile - map.noexeglobs.
Actually, there's more that one mapfile, as we need to
create ones that are specific to the compilation environment.
This means these mapfiles are dynamically generated.
rec.flg files have been updated to ensure that all the
necessary mapfile components are brought down with any
sub-directory bringovers. But, you'll have to generate the
mapfiles yourself. If you see:
ld: fatal: file
usr/src/common/mapfiles/gen/i386_cc_map.noexeglobs: \
stat failed: No such file or directory
then you need to:
% cd $SRC/common/mapfiles/gen
% make
These mapfiles can also be generated from the usr/src/Makefile
"setup" target. A top down make, ie. "nightly" will obviously
do the right thing too.
Note, it's quite possible the use of this mapfile will extend to
many more OSNet components in future as an additional guard
against accidental interposition. Also note, that debugging
capabilities have not been compromised, as the integration of
4934427 (PSARC 2006/526) ensures local function symbols are
available for stack traces etc, regardless of symbol demotion
or stripping.
Have fun.
--
Rod.
|