Comments on: Linkers part 6 http://www.airs.com/blog/archives/43 Ian Lance Taylor Wed, 8 Oct 2008 06:05:42 +0000 http://wordpress.org/?v=1.5.2 Comment on Linkers part 6 by: ncm http://www.airs.com/blog/archives/43#comment-4095 Tue, 04 Sep 2007 21:51:58 +0000 http://www.airs.com/blog/archives/43#comment-4095 The optimization would have to be the default, because nobody would know about it; or, if they did, they'd need apparatus in configure to tell whether it was there and turn it on. Is there something unsafe about the optimization? I suppose a program could dlopen a library that doesn't construct a type T, but uses a virtual member of T not referenced in the main program. You'd like to get an unresolved-symbol error at dlopen time, then, just as when the library references a regular symbol that's not present. But, you 'd also like to have a way to tell the program linker to retain unused virtuals meant to be available for use by dlopened libraries. The optimization would have to be the default, because nobody would know about it; or, if they did, they’d need apparatus in configure to tell whether it was there and turn it on.

Is there something unsafe about the optimization? I suppose a program could dlopen a library that doesn’t construct a type T, but uses a virtual member of T not referenced in the main program. You’d like to get an unresolved-symbol error at dlopen time, then, just as when the library references a regular symbol that’s not present. But, you ‘d also like to have a way to tell the program linker to retain unused virtuals meant to be available for use by dlopened libraries.

]]> Comment on Linkers part 6 by: Ian Lance Taylor http://www.airs.com/blog/archives/43#comment-4075 Tue, 04 Sep 2007 01:36:59 +0000 http://www.airs.com/blog/archives/43#comment-4075 The current GNU linker implemented that optimization for a while, using special relocation types to indicate virtual function calls and the class heirarchy. This information was fed into the garbage collector. This was implemented for eCos. I don't think anybody really uses it, though, and I don't know whether it still works correctly. Using relocation types was the wrong approach. It should be done using a separate side table in an unloaded section. In any case, this optimization requires cooperation with the compiler. It's not particularly hard to implement in the linker as part of a garbage collector to discard unreferenced sections. The current GNU linker implemented that optimization for a while, using special relocation types to indicate virtual function calls and the class heirarchy. This information was fed into the garbage collector. This was implemented for eCos. I don’t think anybody really uses it, though, and I don’t know whether it still works correctly.

Using relocation types was the wrong approach. It should be done using a separate side table in an unloaded section. In any case, this optimization requires cooperation with the compiler. It’s not particularly hard to implement in the linker as part of a garbage collector to discard unreferenced sections.

]]> Comment on Linkers part 6 by: Mark J. Wielaard » Ian Lance Taylor’s Linker Notes http://www.airs.com/blog/archives/43#comment-4028 Fri, 31 Aug 2007 16:22:15 +0000 http://www.airs.com/blog/archives/43#comment-4028 [...] Linkers part 6 - Relocations, Position Dependent Shared Libraries. [...] […] Linkers part 6 - Relocations, Position Dependent Shared Libraries. […]

]]> Comment on Linkers part 6 by: ncm http://www.airs.com/blog/archives/43#comment-4018 Fri, 31 Aug 2007 08:01:51 +0000 http://www.airs.com/blog/archives/43#comment-4018 I'm hoping your linker will implement the omit-uncalled-virtuals optimization, as implemented in Symantecs's linker years back. Naive linkers see the reference to a virtual function implementation in a virtual function table, itself referenced in a constructor, and link the function even though that function cannot be called by the program. You can tell because that offset into the vtable is never used. You can be smarter: that offset is never used with a static "this" type at or below it in the derivation hierarchy. You can be smarter yet: if the "this" type is below it, and that type or one on the way there provides its own implementation, that can't call yours. It's tempting to argue that virtual functions are all in shared libraries, these days, or that program size doesn't matter any more, or that virtual functions aren't so important any more. However, big programs and embedded programs are often linked statically, and cache/VM footprint still matters, and people still insist on making derivation hierarchies. I’m hoping your linker will implement the omit-uncalled-virtuals optimization, as implemented in Symantecs’s linker years back. Naive linkers see the reference to a virtual function implementation in a virtual function table, itself referenced in a constructor, and link the function even though that function cannot be called by the program. You can tell because that offset into the vtable is never used. You can be smarter: that offset is never used with a static “this” type at or below it in the derivation hierarchy. You can be smarter yet: if the “this” type is below it, and that type or one on the way there provides its own implementation, that can’t call yours.

It’s tempting to argue that virtual functions are all in shared libraries, these days, or that program size doesn’t matter any more, or that virtual functions aren’t so important any more. However, big programs and embedded programs are often linked statically, and cache/VM footprint still matters, and people still insist on making derivation hierarchies.

]]>