This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [web] FAQ- dynamic loading & RTTI

Gerald Pfeifer wrote:
> Fine, thanks!  Nathan, please go ahead and commit with Mark's changes.
Ta for the suggestions, this is what I committed,

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

The new C++ ABI in the GCC 3.0 series uses address comparisons,
rather than string compares, to determine type equality. This leads to
better performance. Like other objects that have to be 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. With static linking all of these symbols are resolved at
link time, but with dynamic linking, 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 will have to
       specify this as "-Wl,-E" if you are invoking the linker in the usual
       manner from the compiler driver, g++). 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. (This is not an exhaustive list of the kind of objects which have
vague linkage and are expected to be resolved during linking & loading.)

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 more details about the way that GCC implements these and other
C++ features, please read the ABI specification. Note the
std::typeinfo_t objects which must be resolved all begin with "_ZTS".
Refer to ld's documentation for a description of the "-E" & "-Bsymbolic"

Dr Nathan Sidwell   ::   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?' : :

Attachment: faq.patch
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]