Comments on: Linkers part 15 http://www.airs.com/blog/archives/52 Ian Lance Taylor Mon, 26 Jul 2010 08:38:18 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Joe Buck http://www.airs.com/blog/archives/52/comment-page-1#comment-5020 Joe Buck Tue, 09 Oct 2007 04:04:48 +0000 http://www.airs.com/blog/archives/52#comment-5020 There's another related feature of most C++ implementations, invented by Stroustrup (or one of his colleagues), used also by g++. Rather than emitting the virtual function table definition in every object file and using COMDAT, it is emitted in the .o file that contains the definition of the first non-inline virtual function. By the one-definition rule there must be only one such file; doing it this way saves considerable space in .o files. COMDAT is used if all of the functions are defined inline or in the class definition. The typeinfo object for the class is handled in the same way, as are "out-of-line" definitions for virtual functions that are inline. This optimization sometimes leads to confusing messages from the linker if there is a missing definition for this first virtual function. I recall that Sun's linker would generate a message saying something like virtual function table for class Foo is undefined [ hint: see if the first non-inline virtual function of Foo is defined ] while the GNU linker only gave the first message (or would complain about a missing typeinfo object). There’s another related feature of most C++ implementations, invented by Stroustrup (or one of his colleagues), used also by g++. Rather than emitting the virtual function table definition in every object file and using COMDAT, it is emitted in the .o file that contains the definition of the first non-inline virtual function. By the one-definition rule there must be only one such file; doing it this way saves considerable space in .o files. COMDAT is used if all of the functions are defined inline or in the class definition. The typeinfo object for the class is handled in the same way, as are “out-of-line” definitions for virtual functions that are inline.

This optimization sometimes leads to confusing messages from the linker if there is a missing definition for this first virtual function. I recall that Sun’s linker would generate a message saying something like

virtual function table for class Foo is undefined
[ hint: see if the first non-inline virtual function of Foo is defined ]

while the GNU linker only gave the first message (or would complain about a missing typeinfo object).

]]> By: tromey http://www.airs.com/blog/archives/52/comment-page-1#comment-4549 tromey Thu, 20 Sep 2007 20:36:02 +0000 http://www.airs.com/blog/archives/52#comment-4549 FWIW, for the compile server I'm looking into a repository-like approach for things that would ordinarily have vague linkage. Or, perhaps I'll generate them once and then link each into the object files requested by the compilation job. The latter approach may be somewhat slower but has the benefit of creating objects with the expected contents. Luckily all this is a ways off, so I don't have to make any hard decisions soon. FWIW, for the compile server I’m looking into a repository-like approach for things that would ordinarily have vague linkage. Or, perhaps I’ll generate them once and then link each into the object files requested by the compilation job. The latter approach may be somewhat slower but has the benefit of creating objects with the expected contents.

Luckily all this is a ways off, so I don’t have to make any hard decisions soon.

]]>