At 06:23 PM 10/1/2007, Wei Dai wrote: >In theory, the linker *should* be able to discard any code that >isn't necessary from the final executable.
The rule of linkers from way back is that all functions in a compilation unit are linked. The linker, as a rule, doesn't know what is "used" or not, merely what is referenced, that is, reference implies use. This made perfect sense in an era where assembly language hacks were common (think absolute addresses), which destroyed any hope of getting it right in general. It's less sensible when object code is almost universally generated within a high-level language context. While it's obvious these days, in the past there was no notion of an "entry point" that was universal enough to be able to root a tree (or forest, as with a DLL) in order to be able to perform dependency tracking. Long ago, I worked with code that used JMP tables for indexed system calls; there was no way to specify the address in that JMP instruction (an entry point) from any other JMP instruction. I can't say I'm current with what people have done to remedy this. Function-level linking is one way of addressing this, but it's not universal. There would still remain issues with cross-language linking, etc., that make this risky to turn on by default. The real point is that, historically, the "reference implies use" principle isn't the worst. The work-around is to put each function into its own compilation unit. This is a pain, but it pretty much always works because then unit dependency maps to function dependency. As for debugging link-size issues, there's DUMPBIN for MSVC. Eric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
