Re: How do linkers deal with C++ duplicate code?

In comp.compilers John R Levine <johnl@iecc.com> writes:


>-- Name mangling I understand, to deal with routines that have the
>same name but different input and output types. Varieties of that go
>way back, to PL/I "generic" procedures in the 1960s


As a minor detail, note that C++ name mangling typically only
describes the input parameter types (which may of course include
pointers and references; by input types I mean the C++ sense, not the
logical sense). It does not describe the return type.


That is,
        int foo (int i) {}
and
        double foo (int i) {}
will often use the same name for foo. g++ uses foo__Fi for both.


>-- Templates and extern inline. This I understand the least. The
>problem is that with separate compilation, multiple modules can
>contain identical (or at least equivalent) copies of expanded
>templated routines and extern inlines. One approach is to pretend
>they're all static and live with the code bloat, although as recently
>noted, the bloat can be pretty horrible. But some systems actually
>identify and discard the duplicates. What do they do, treat them as
>name-mangled common blocks full of code and discard all but one of
>them? Something cleverer?


g++ and the GNU linker do what you suggest on ELF systems. As I
recall, the ideas were mostly worked out by Jason Merrill at Cygnus.


When code is compiled that requires a particular template function,
the code for that template function is compiled as well. It is placed
in a separate section with a special name:
        .gnu.linkonce.t.MANGLED_FUNCTION_NAME


The linker recognizes sections with names of the form .gnu.linkonce.*.
It arranges to only link a single copy of each such section into the
final executable.


The linker has internal support for some slightly more complex cases,
such as checking that the duplicate sections have the same size, but
g++ does not currently use that support.




The GNU linker has a number of obscure features, particularly in the
area of ELF and specifically Linux shared library support.


The current version of the linker supports symbol versioning, which
acts in conjunction with the dynamic linker to permit an ABI change in
a shared library without requiring a new major version of the shared
library and without invaliding existing programs. This was done
mainly by Eric Youngdale as a reimplementation and extension of some
features of the Sun Solaris linker.


The current version of the linker supports warning symbols on ELF and
a.out targets. This permits a library writer to cause the linker to
automatically emit a warning when a particular function (such as the
rather unsafe ANSI C library function gets) is used.


Recent versions of egcs/g++ and development snapshots of the linker
support global constructor/destructor priority ordering, so that the
developer can directly control the order in which global objects found
in a library are constructed. There are various mechanisms to do this
in the C++ language itself, of course, but I don't know of another
approach with no runtime cost. This was implemented by Jason Merrill
and myself.


Development snapshots of the linker include some support for garbage
collection of ELF files, discarding unwanted functions. The
interesting aspect is the ability, with compiler support, to discard
unused virtual functions. The compiler tells the linker which entries
in a virtual function table are used. The linker notes which virtual
function table entries are never required, zeroes them out, and
garbage collects the code for the virtual functions. This was
implemented by Richard Henderson at Cygnus.


Ian Taylor
ian@cygnus.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.