On 30 Nov 2014 09:20, "Johannes Pfau via D.gnu" <d.gnu@puremagic.com> wrote: > > Am Sun, 30 Nov 2014 01:52:57 +0000 > schrieb "Mike" <n...@none.com>: > > > This has been brought up before: > > [1] > > http://forum.dlang.org/post/cqzazaqxpwezignix...@forum.dlang.org > > [2] > > http://forum.dlang.org/post/zapxhodqmotriapue...@forum.dlang.org > > > > But I'd like to know what GDC's long term plans are to enable > > removing dead code from executables. > > > > (1) Adding a D-specific linker script in GDC that gets > > automagically passed to the linker? > > AFAIK that's almost impossible. You can't replicate the complete linker > scripts for all architectures with all their special cases etc. It > could be possible to place all ModuleInfos in a special section then > pass a implicit linker script which extends the standard script and > only handles this section. > > > (2) Adding a D-specific linker script to binutils? > > (3) LTO in GCC/binutils? > > LTO is certainly a long-time (though low priority) goal. AFAIK it's > mostly about speed optimization though, not size. > > > (2) sounds a little weird, but I got the impression from > > discussion [1] that that was part of the plan. I don't > > understand why binutils should have to know about D's codegen, > > but there's a lot of things I don't understand. > > The linker scripts also know about some details of the C/C++ codegen. > For example attribute(constructor) needs support from linker scripts. > (KEEP, SORT_NONE, PROVIDE_HIDDEN or similar) Without this support > constructor calls would be eliminated by these optimization flags as > well. So it's kinda reasonable. >
To contrast with another young language. Go/Android has linker support in binutils when I last looked. Heck, Go runtime even has Linux kernel support code somewhere (though I don't think the core Linux devs liked it).
