Bug 13117 – Executable size of hello world explodes from 472K to 2.7M

Compiled with dmd_2.066.0~b3-0_amd64 (or ~b2) hello world executable becomes 2.7 megabytes while with 2.065 it's 472 kilobytes. import std.stdio; void main() { writeln("hello"); }

Issue does not occur in Windows platform. -m32 With git head: 145,436 bytes With 2.065: 138,268 bytes -m64 With git head: 259,584 bytes With 2.065: 257,536 bytes

Not again! Dammit, this should be tested for in the autotester suite.

I just tried this, and am seeing 394,000 size executables. I cannot reproduce your results.

Ok here's more info then: % uname -a Linux laptop 3.11.0-20-generic #35-Ubuntu SMP Fri May 2 21:32:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux % file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x6dbff8d6e93645b94b809ad602141ecf49ed261c, not stripped % objdump -h hello | egrep -v 'CONTENTS|ALLOC' hello: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 0000001c 0000000000400200 0000000000400200 00000200 2**0 1 .note.ABI-tag 00000020 000000000040021c 000000000040021c 0000021c 2**2 2 .note.gnu.build-id 00000024 000000000040023c 000000000040023c 0000023c 2**2 3 .gnu.hash 00003574 0000000000400260 0000000000400260 00000260 2**3 4 .dynsym 0000b6a0 00000000004037d8 00000000004037d8 000037d8 2**3 5 .dynstr 0001eb0b 000000000040ee78 000000000040ee78 0000ee78 2**0 6 .gnu.version 00000f38 000000000042d984 000000000042d984 0002d984 2**1 7 .gnu.version_r 00000090 000000000042e8c0 000000000042e8c0 0002e8c0 2**3 8 .rela.dyn 00000168 000000000042e950 000000000042e950 0002e950 2**3 9 .rela.plt 00000648 000000000042eab8 000000000042eab8 0002eab8 2**3 10 .init 0000001a 000000000042f100 000000000042f100 0002f100 2**2 11 .plt 00000440 000000000042f120 000000000042f120 0002f120 2**4 12 .text 00026f12 000000000042f560 000000000042f560 0002f560 2**4 13 .fini 00000009 0000000000456474 0000000000456474 00056474 2**2 14 .rodata 000052b0 0000000000456480 0000000000456480 00056480 2**4 15 .deh_eh 000002d0 000000000045b730 000000000045b730 0005b730 2**3 16 .minfo 00000108 000000000045ba00 000000000045ba00 0005ba00 2**3 17 .eh_frame_hdr 0000003c 000000000045bb08 000000000045bb08 0005bb08 2**2 18 .eh_frame 000000e4 000000000045bb48 000000000045bb48 0005bb48 2**3 19 .tdata 00000010 000000000065cbe0 000000000065cbe0 0025cbe0 2**4 20 .tbss 00000040 000000000065cbf0 000000000065cbf0 0025cbf0 2**4 21 .init_array 00000010 000000000065cbf0 000000000065cbf0 0025cbf0 2**3 22 .fini_array 00000020 000000000065cc00 000000000065cc00 0025cc00 2**3 23 .jcr 00000008 000000000065cc20 000000000065cc20 0025cc20 2**3 24 .data.rel.ro 00004170 000000000065cc30 000000000065cc30 0025cc30 2**4 25 .dynamic 00000200 0000000000660da0 0000000000660da0 00260da0 2**3 26 .got 00000060 0000000000660fa0 0000000000660fa0 00260fa0 2**3 27 .got.plt 00000230 0000000000661000 0000000000661000 00261000 2**3 28 .data 00006770 0000000000661230 0000000000661230 00261230 2**4 29 .bss 00000730 00000000006679a0 00000000006679a0 002679a0 2**4 30 .comment 00000071 0000000000000000 0000000000000000 002679a0 2**0 The sizes of all sections amount to 0x66fad which is only 421805 bytes. The rest of the 2.7 megabytes seem to be between sections .eh_frame and .tdata. What could be there?

Looked with xxd, there's nothing but a bunch of zeros between those sections.

Only happens with ld.bfd (my version is 2.23.2). For some reason the output file contains a single RWE segment with .text and .bss. This also only happens with the libphobos2.a of the distributed binary. I cannot reproduce the issue when building libphobos2.a myself.

Doesn't happen with PIC code either. dmd -fPIC main

This problem seems to stem from mixed writeable flags for the .deh/.minfo sections in PIC/non-PIC code. The ld.bfd linker would still try to bracket the sections, even though it previously mapped them to different segments, thereby creating one huge segment which contains all read-only and all writeable data plus the big hole in between them. https://github.com/D-Programming-Language/dmd/pull/3778

Bug was introduced with https://github.com/D-Programming-Language/dmd/pull/3187 which fixed Issue 11171 - Text relocations in Phobos shared library.

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f8bcda05a8193c4180815d067713cf4b6e7884bf fix Issue 13117 - Executable size of hello world explodes from 472K to 2.7M - This problem seems to stem from mixed writeable flags for the .deh/.minfo sections in PIC/non-PIC code. The ld.bfd linker would still try to bracket the sections, even though it previously mapped them to different segments, thereby creating one huge segment which contains all read-only and all writeable data plus the big hole in between them. - fixed by always marking those sections as writeable https://github.com/D-Programming-Language/dmd/commit/5f3a83a890a3e3f106e89d5423993eae9945dc3b Merge pull request #3778 from MartinNowak/fix13117 fix Issue 13117 - Executable size of hello world explodes from 472K to 2.7M

The resolution of this bug implies that the libphobos2.a we're shipping is build with -fPIC. See issue 13149.

Commit pushed to 2.066 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/239394c6ea98a281c51f95977612cc41866f0b4f Merge pull request #3778 from MartinNowak/fix13117 fix Issue 13117 - Executable size of hello world explodes from 472K to 2.7M

Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/239394c6ea98a281c51f95977612cc41866f0b4f Merge pull request #3778 from MartinNowak/fix13117