On 30.12.2015 13:25, Benjamin Thaut wrote:
On Wednesday, 30 December 2015 at 09:43:32 UTC, Rainer Schuetze
wrote:
I noticed something similar recently when compiling a C file with
/Gy, see
https://github.com/D-Programming-Language/druntime/pull/1446#issuecomment-160880021
The compiler puts all functions into COMDATs, but they are all
still linked in if only a single symbol is referenced, even if
linked with /OPT:REF.
So I suspect this is not an issue with dmd, but the Microsoft
linker. I still wonder whether the approach to use "function level
linking" works at all for Win64.
I noticed by looking at some object file dumps that dmd puts
each
function into its own section, but data symbols, like
initializers, are
all merged into the same section. Could this be the root
issue?
Having all data in a single section misses some possible
optimizations, and it might be the reason for the behavior in your
case (you can check this with "dumpbin /all objectfile"), but the
issue above does not contain any data.
So if I understand this correctly the microsoft linker only strips
unused comdats, otherwise always the entire object file gets pulled
in?
I tried to reproduce the issue right now, but failed to do so (both with
a C file compiled with /Gy and a D compiled). Only referenced COMDATs
where included in a link, not other COMDATs in the same object file.
Maybe it was an issue with my build script back then.
For me stripping of individual data symbols not working is actually a
good thing, if it doesn't work, I can't break it. ;-)
Please note that building with -lib puts every function/declaration into
it's own object file inside the library, and unused class declarations
are no longer in the linked executable.
