Lib change leads to larger executables

[Frits van Bommel]

Sean Kelly wrote:
> Frits van Bommel wrote:
>> Sean Kelly wrote:
>>> That makes complete sense.  It's irritating that such matches pull in 
>>> the entire object, but at least the process is straightforward and 
>>> logical.
>>
>> Of course, if matches didn't pull in the entire object then static 
>> constructors/destructors, unittests and exceptions wouldn't work 
>> without some way to flag specific sections as "always pull this in if 
>> anything (or even better: if _certain things_) are pulled in" or "when 
>> this is pulled in, also pull in X and Y even though they're not 
>> referenced" or something similar...
> 
> Hm... so how does segment-level linking work at all?

Well, ld has a switch called --gc-sections, which basically... wait for 
it... garbage collects the sections. :)
 From what I understand, this currently breaks DMD exception handling on 
Linux, since nothing explicitly refers to the sections containing the data.
C++ exceptions work fine AFAIK, presumably because the default linker 
script[1] explicitly tells ld to keep .eh_frame sections even if 
unreferenced. It does the same for quite some other sections, including 
.ctors and .dtors (which DMD uses to set up the linked module list).

So presumably it first selects the objects to be linked in and then uses 
the program entry point and those sections as the "root pointers" for 
the --gc-sections switch if used.

This would mean that if a module gets pulled in, its .ctors section (if 
any) gets kept, and that references (indirectly) the static 
constructors, destructors and unit tests. So that makes me think ld may 
have the same issue as optlink, since Walter has shown that without 
--gc-sections ld also pulls in whole object files (even if the 
corresponding modules are not necessarily imported by the program). 
Unless ld somehow handles libraries in a smarter manner...


[1] use 'ld --verbose' to see it.