Consider this struct definition:
struct Test1 {
byte arr[1024 * 1024 * 10];
}
DMD for Windows places 10 MB into the BSS section, whereas DMD on Linux fails to use the equivalent .bss section.
This is not always the case, as this declaration shows:
struct Test2 {
__gshared byte arr[1024 * 1024 * 10];
}
Now the struct is correctly placed inside .bss. But this can easily lead to bad runtime behavior, as the last test case shows:
struct Test {
byte arr1[1024 * 1024 * 10];
__gshared byte arr2[1024 * 1024 * 10];
}
int main() {
Test test;
return 0;
}
This will SEGFAULT when the stack variable test is about to be initialized.
Other observations:
- Placing the array outside the struct, directly at module level results in a small executable size. (It probably uses .tbss here correctly for thread local storage?)
- This and the above tests can be reproduced with GDC as well, so I assume the bug is at the front-end stage.
- How is MacOSX affected ?
- What is the scope of __gshared, what can be attributed with it?
Comment #1 by doob — 2012-01-19T06:24:00Z
On Mac OS X it will result in a 10.7 MB executable when "__gshared" is not used.
Comment #2 by Marco.Leise — 2012-01-19T07:18:03Z
My personal 'fix' is to use this code - adapted from the Windows section in toobj.c:
#if ELFOBJ
if (sinit->Sdt &&
sinit->Sdt->dt == DT_azeros &&
sinit->Sdt->DTnext == NULL &&
!global.params.multiobj)
{
sinit->Sseg = UDATA;
}
else
{
sinit->Sseg = CDATA;
}
#endif
It seems to work with the dmd Makefile for Phobos/druntime itself and on my own program. I don't know the compiler source code, but from what I read briefly, "global.params.multiobj" means: compile to single .obj/.o files. If so, then this would effect unity builds only (?)
Comment #3 by doob — 2012-01-19T08:08:49Z
It needs a fix for Mac OS X as well.
Comment #4 by Marco.Leise — 2014-11-04T06:59:55Z
Three years later and this is still open. I don't think it is the difficulty of the problem. I'm raising this to 'normal'. Here is a test case that _should_ result in a few KiB executable, but creates a 7 MiB one. Every instantiation of the templated structs adds 1 MiB. Some, but not all of these unnecessary .inits are also accessible at runtime:
---------8<-------------
import std.typetuple;
import std.stdio;
struct StuffDefault(T) { T[1024 * 1024] m_data; }
struct StuffVoid(T) { T[1024 * 1024] m_data = void; }
struct StuffZero(T) { T[1024 * 1024] m_data = 0; }
void main(string[] args)
{
alias Ts = TypeTuple!(
StuffDefault!void,
StuffVoid!void,
StuffDefault!ubyte,
StuffVoid!ubyte,
StuffZero!ubyte,
StuffVoid!char,
StuffZero!char,
);
// .inits visible at runtime
foreach (T; Ts) {
writefln("Does %s have a superfluous init? %s",
T.stringof, typeid(T).init.ptr is null ? "no" : "YES");
}
}
----------->8------------
Prints:
Does StuffDefault!void have a superfluous init? no
Does StuffVoid!void have a superfluous init? YES
Does StuffDefault!ubyte have a superfluous init? no
Does StuffVoid!ubyte have a superfluous init? YES
Does StuffZero!ubyte have a superfluous init? YES
Does StuffVoid!char have a superfluous init? YES
Does StuffZero!char have a superfluous init? YES
Comment #5 by pro.mathias.lang — 2020-05-15T03:36:40Z
Just tested on Mac OSX. Modified to use `core.stdc.stdio : printf` and `alias TypeTuple(T...) = T;` to remove Phobos imports.
The test case now returns false for everything (the pointer is null, but not the length). The binary is still huge (8.1 Mbs), even with LDC (5.5Mb).
```
% objdump -section-headers foo
foo: file format Mach-O 64-bit x86-64
Sections:
Idx Name Size VMA Type
0 __text 00179940 00000001000011f0 TEXT
1 __stubs 00003f54 000000010017ab30 TEXT
2 __stub_helper 00000984 000000010017ea84 TEXT
3 __cstring 0000fb63 000000010017f410 DATA
4 __const 0003f632 000000010018ef80 DATA
5 __gcc_except_tab 0000240c 00000001001ce5b4 DATA
6 __ustring 00000334 00000001001d09c0 DATA
7 __unwind_info 00007084 00000001001d0cf4 DATA
8 __eh_frame 0006b278 00000001001d7d78 DATA
9 __got 00001c00 0000000100243000 DATA
10 __mod_init_func 00000020 0000000100244c00 DATA
11 __mod_term_func 00000008 0000000100244c20 DATA
12 __const 0000baa8 0000000100244c30 DATA
13 __la_symbol_ptr 00005470 0000000100251000 DATA
14 __data 00035668 0000000100256480 DATA
15 .minfo 00000508 000000010028bae8 DATA
16 __thread_vars 00000468 000000010028bff0 DATA
17 __thread_ptrs 00000048 000000010028c458 DATA
18 __thread_data 00001441 000000010028c4a0 DATA
19 __thread_bss 00000360 000000010028d8f0 DATA
20 __common 00000920 000000010028dc50 BSS
21 __bss 00000001 000000010028e570 BSS
```
Comment #6 by pro.mathias.lang — 2020-05-15T04:06:33Z
Comment #7 by pro.mathias.lang — 2020-05-15T04:08:34Z
*** Issue 2642 has been marked as a duplicate of this issue. ***
Comment #8 by kinke — 2020-05-15T10:55:40Z
(In reply to Mathias LANG from comment #5)
> Just tested on Mac OSX. Modified to use `core.stdc.stdio : printf` and
> `alias TypeTuple(T...) = T;` to remove Phobos imports.
>
> The test case now returns false for everything (the pointer is null, but not
> the length). The binary is still huge (8.1 Mbs), even with LDC (5.5Mb).
That must have another reason though. On Win64 and with DMD 2.091 / LDC 1.21, the 64-bit .obj file size is 27 KB (~2 KB overhead for the object.RTInfoImpl bit mask for the precise GC) and contains no struct initializers at all. The final executable size is < 0.5 MB when linking MSVC statically, and < 0.25 MB when linking MSVC dynamically.
I.e., seems totally fixed.
Comment #9 by kinke — 2020-05-15T10:59:43Z
(In reply to kinke from comment #8)
> ~2 KB overhead for the object.RTInfoImpl bit mask for the precise GC
Correction: overhead is 16 KB.
Comment #10 by robert.schadek — 2024-12-13T17:57:49Z