[web] FAQ- dynamic loading & RTTI

[Nathan Sidwell <nathan at codesourcery dot com>]

Hi,
here's a patch to the faq describing the 3.0 issues with dynamic loading
and rtti. I've attached the diff as a binary file, so that it doesn't
look like HTML. Here's that actual text


dynamic_cast, throw, typeid don't work with shared libraries.

The new C++ abi in GCC 3.0 uses address comparisons rather than
string compares to determine type equality. This leads to better
performance. Like other objects that have to present in the final
executable, these std::typeinfo_t objects have what is called vague
linkage because they are not tightly bound to any one particular
translation unit (object file). The compiler has to emit them in any
translation unit that requires their presence, and then rely on the linking
and loading process to make sure that only one of them is active in the
final executable. For static linkage, this is all resolved at link time, but
for dynamic linkage, further resolution occurs at load time. You have to
ensure that objects within a shared library are resolved against objects
in the executable and other shared libraries.

       For a program which is linked against a shared library, no
       additional precautions need taking. 
       You cannot create a shared library with the -Bsymbolic option,
       as that prevents the resolution described above. 
       If you use dlopen to explicitly load code from a shared library,
       you must do several things. First, export global symbols from
       the executable by linking it with the -E flag. You must also
       make the external symbols in the loaded library available for
       subsequent libraries by providing the RTLD_GLOBAL flag to
       dlopen. The symbol resolution can be immediate or lazy. 

Template instantiations are another, user visible, case of objects with
vague linkage, which needs similar resolution. If you do not take the
above precautions, you may discover that a template instantiation with
the same argument list, but instantiated in multiple translation units, has
several addresses, depending in which translation unit the address is
taken.

If you are worried about different objects with the same name colliding
during the linking or loading process, then you should use namespaces
to disambiguate them. Giving distinct objects with global linkage the
same name is a violation of the One Definition Rule (ODR)
[basic.def.odr].

For details of vague linkage and other aspects of the ABI such as how
type information is encoded, refer the the C++ ABI specification at C++
ABI. Note the type info objects which must be resolved all begin with
'_ZTS'. Refer to ld's documentation for a description of the -E flag.


ok?

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Attachment: faq.patch
Description: Binary data