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

David Stes <stes@mundivia.es>
20 Aug 1998 22:56:10 -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)
Re: How do linkers deal with C++ duplicate code? jacob@jacob.remcomp.fr (1998-08-22)
[8 later articles]
| List of all articles for this month |

From: David Stes <stes@mundivia.es>
Newsgroups: comp.compilers
Date: 20 Aug 1998 22:56:10 -0400
Organization: Compilers Central
References: 98-08-147
Keywords: linker, C++, comment

John R Levine wrote:
>
> -- Global initializers and destructors I understand, too [...]


There exists an alternative to the approach for global initializers,
as you described it, that may be interesting.


I have no idea whether this alternative is a well-known trick or not ...


I personally think it's rather nice, but in fact, many people consider
it a horrible and terrible hack ! (I admit that at first, I also
thought it was rather fishy).


It's a way to support global initializers by using an (old) feature
that already is available in many C linkers, namely the common storage
linkage model (so that no new linker feature is needed).


You can have each module define a global as its initializer routine,
and all other modules declare the same global as an _uninitialized_
global.


For example, a module "foo" can define the global F as its initializer
and declares the global B as an uninitialized global, while a module
"bar" does the opposite, and declares F as uninitialized and defines B
as its initializer.


The linker on most (but not all) Unix systems will then _merge_ the
_multiple_ definitions for the globals, and use the unique definition,
or use zero (0) for those multiply defined globals that remain
uninitialized, depending on what modules where specified on the link
line.


Like this, you don't have to collect the initializers when linking,
you just link all modules together, and depending on which modules
were specified on the command line (when linking), the program will
find at runtime some symbols to be zero (so you don't have to call
those routines) and some symbols will be non-zero (those are the
global initializers to call).


There's an Objective-C package that uses this trick on some platforms,
at http://sunsite.unc.edu/pub/Linux/devel/lang/objc/.
[I don't mind the grossness, I used to hand-punch 360/20 object code
into cards on keypunches and you can't get much grosser than that.
But this sounds awfully fragile, you have to hand-enumerate every
possible thing that might have an initializer somewhere and it won't
complain if you forget something. -John]
--


Post a followup to this message

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