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

johnmce@world.std.com (John McEnerney)
20 Aug 1998 22:53:05 -0400

          From comp.compilers

Related articles
How do linkers deal with C++ duplicate code? johnl@iecc.com (John R Levine) (1998-08-20)
Re: How do linkers deal with C++ duplicate code? johnmce@world.std.com (1998-08-20)
Re: How do linkers deal with C++ duplicate code? stes@mundivia.es (David Stes) (1998-08-20)
Re: How do linkers deal with C++ duplicate code? urs@cs.ucsb.edu (Urs Hoelzle) (1998-08-20)
Re: How do linkers deal with C++ duplicate code? dlmoore@molalla.net (David L Moore) (1998-08-22)
Re: How do linkers deal with C++ duplicate code? dwight@pentasoft.com (1998-08-22)
Re: How do linkers deal with C++ duplicate code? stes@mundivia.es (David Stes) (1998-08-22)
Re: How do linkers deal with C++ duplicate code? saroj@bear.com (1998-08-22)
[8 later articles]
| List of all articles for this month |

From: johnmce@world.std.com (John McEnerney)
Newsgroups: comp.compilers
Date: 20 Aug 1998 22:53:05 -0400
Organization: Metrowerks, Inc.
References: 98-08-147
Keywords: linker, C++

John R Levine <johnl@iecc.com> wrote:


> -- 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?


One possibility is to compare the size/contents of duplicate modules and,
if they match, discard all but one; otherwise report some sort of error.
This is a little expensive, but probably not -too- expensive, and might be
a good way to code a linker if it needed to work with different compilers.
In fact, it might be a worthwhile optimization to perform on -all- code
modules, whether or not they have the same mangled name, because (1) there
won't typically be very many with exactly the same size so it should be
fast enough to hash on size and then do some quick compares before doing a
full compare and (2) template instantiation, e.g. a vector of 2 different
pointer types, may well end up generating different symbols with identical
executable code.


In the Metrowerks C/C++ compilers and linkers, we use a storage-class
attribute that indicates that a symbol is expected to have multiple
definitions, and that all are guaranteed by the compiler to have identical
contents.


(Obviously this would be a lie if you compile one version of the source
into a library and link it with objects from a different version of the
source, but our IDE is not typically used in that fashion)


If there are multiple definitions of the same symbol and all are marked
with this "multidef" storage class, then the linker just picks one and
ignores the rest. If there are any non-multidef definitions then it is an
error.
--
John McEnerney (mcenerney@metrowerks.com)
--


Post a followup to this message

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