On 28.12.2015 13:05, Benjamin Thaut wrote:
My current work on the D compiler lead me to the following test case
which I put through a unmodified version of dmd 2.069.2
import core.stdc.stdio;
struct UnusedStruct
{
int i = 3;
float f = 4.0f;
};
class UnusedClass
{
int i = 2;
float f = 5.0f;
};
void main(string[] args)
{
printf("Hello World!");
}
When compiling this on windows with dmd -m64 main.d -L/MAP
and then inspecting the map file I noticed that the following 4 data
symbols end up in the final executable although they shouldn't be used.
0003:00000a90 _D4main12UnusedStruct6__initZ 0000000140046a90
main.obj
0003:00000ad0 _D4main11UnusedClass6__initZ 0000000140046ad0
main.obj
0003:00000af0 _D4main11UnusedClass7__ClassZ 0000000140046af0
main.obj
0003:00000ba0 _D4main11UnusedClass6__vtblZ 0000000140046ba0
main.obj
For the struct this is the initializer, for the class its the
initializer, class info and vtbl.
Is this behavior correct? Shouldn't UnusedStruct and UnusedClass be
stripped completely from the binary? Is this somehow connected to the
module info / object.factory?
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.
