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