gcc: Vague Linkage
1
1 7.3 Vague Linkage
1 =================
1
1 There are several constructs in C++ that require space in the object
1 file but are not clearly tied to a single translation unit. We say that
1 these constructs have "vague linkage". Typically such constructs are
1 emitted wherever they are needed, though sometimes we can be more
1 clever.
1
1 Inline Functions
1 Inline functions are typically defined in a header file which can
1 be included in many different compilations. Hopefully they can
1 usually be inlined, but sometimes an out-of-line copy is necessary,
1 if the address of the function is taken or if inlining fails. In
1 general, we emit an out-of-line copy in all translation units where
1 one is needed. As an exception, we only emit inline virtual
1 functions with the vtable, since it always requires a copy.
1
1 Local static variables and string constants used in an inline
1 function are also considered to have vague linkage, since they must
1 be shared between all inlined and out-of-line instances of the
1 function.
1
1 VTables
1 C++ virtual functions are implemented in most compilers using a
1 lookup table, known as a vtable. The vtable contains pointers to
1 the virtual functions provided by a class, and each object of the
1 class contains a pointer to its vtable (or vtables, in some
1 multiple-inheritance situations). If the class declares any
1 non-inline, non-pure virtual functions, the first one is chosen as
1 the "key method" for the class, and the vtable is only emitted in
1 the translation unit where the key method is defined.
1
1 _Note:_ If the chosen key method is later defined as inline, the
1 vtable is still emitted in every translation unit that defines it.
1 Make sure that any inline virtuals are declared inline in the class
1 body, even if they are not defined there.
1
1 'type_info' objects
1 C++ requires information about types to be written out in order to
1 implement 'dynamic_cast', 'typeid' and exception handling. For
1 polymorphic classes (classes with virtual functions), the
1 'type_info' object is written out along with the vtable so that
1 'dynamic_cast' can determine the dynamic type of a class object at
1 run time. For all other types, we write out the 'type_info' object
1 when it is used: when applying 'typeid' to an expression, throwing
1 an object, or referring to a type in a catch clause or exception
1 specification.
1
1 Template Instantiations
1 Most everything in this section also applies to template
11 instantiations, but there are other options as well. ⇒Where's
the Template? Template Instantiation.
1
1 When used with GNU ld version 2.8 or later on an ELF system such as
1 GNU/Linux or Solaris 2, or on Microsoft Windows, duplicate copies of
1 these constructs will be discarded at link time. This is known as
1 COMDAT support.
1
1 On targets that don't support COMDAT, but do support weak symbols, GCC
1 uses them. This way one copy overrides all the others, but the unused
1 copies still take up space in the executable.
1
1 For targets that do not support either COMDAT or weak symbols, most
1 entities with vague linkage are emitted as local symbols to avoid
1 duplicate definition errors from the linker. This does not happen for
1 local statics in inlines, however, as having multiple copies almost
1 certainly breaks things.
1
1 ⇒Declarations and Definitions in One Header C++ Interface, for
1 another way to control placement of these constructs.
1