Lib change leads to larger executables

kris foo at bar.com
Wed Feb 21 15:05:37 PST 2007


Pragma wrote:
> Kristian Kilpi wrote:
> 
>> On Wed, 21 Feb 2007 11:00:44 +0200, Walter Bright 
>> <newshound at digitalmars.com> wrote:
>>
>>>> It does, but increases the exe size of the first example from 180kb 
>>>> to 617kb!
>>>
>>>  > 180kb is when compiled using build/rebuild/jake etc (no library) 
>>> and the 617kb
>>>  > is when using dmd+lib only. Same flags in both cases: none at all
>>>
>>> Let's say you have a template instance, TI. It is declared in two 
>>> modules, M1 and M2:
>>>
>>> -----------M1------------
>>> TI
>>> A
>>> -----------M2------------
>>> TI
>>> B
>>> -------------------------
>>>
>>> M1 also declares A, and M2 also declares B. Now, the linker is 
>>> looking to resolve TI, and the first one it finds is one in M1, and 
>>> so links in M1. Later on, it needs to resolve B, and so links in M2. 
>>> The redundant TI is discarded (because it's a COMDAT).
>>>
>>> However, suppose the program never references A, and A is a chunk of 
>>> code that pulls in lots of other bloat. This could make the 
>>> executable much larger than if, in resolving TI, it had picked M2 
>>> instead.
>>>
>>> You can control which module containing TI will be pulled in by the 
>>> linker to resolve TI, by specifying that module first to lib.exe.
>>>
>>> You can also put TI in a third module that has neither A nor B in it. 
>>> When compiling M1 and M2, import that third module, so TI won't be 
>>> generated for M1 or M2.
>>
>>
>> Here's a quick thought. (It's probably too impractical/absurd. ;) ) 
>> Could template instances to be put to their own, separate modules? 
>> Then the linker will find a module containing the template instance 
>> only, and no bloat will be pulled in with it. I don't know if this 
>> would require the compiler to generate separate, extra .obj files for 
>> template instances or something.
> 
> 
> Nice idea, but I'd rather see the librarian to (optionally?) do this job 
> instead.  It would avoid any complications for the existing toolchain by 
> not introducing any behavior that is radically different from other 
> platforms (i.e. "foo.d" ==> "foo.obj" and "foo-t.obj").
> 
> Now if you're talking about breaking each-and-every COMDAT out into it's 
> own .obj, then having the librarian do it is a must.  I can't imagine 
> what my workspace would look like otherwise.
> 
> Either way, all this involves the rather messy business of turning each 
> COMDAT fixup reference within an .obj file into an EXTERN.  I doubt that 
> the DMD/DMC backend would make this job easy (I could be wrong!), so 
> again, putting the job elsewhere (librarian) might be easier to maintain.
> 


Just to clarify the current situation: the ballooned exe file has 
nothing to do with templates. There are no templates involved in that 
particular issue, and it appears the prior template demons have been 
driven under the bridge for the interim. There is some progress here, 
but it led to the uncovering of another problem ;)




More information about the Digitalmars-d mailing list