This has been brought up before:
[1] http://forum.dlang.org/post/cqzazaqxpwezignixuds@forum.dlang.org
[2] http://forum.dlang.org/post/zapxhodqmotriapuefvm@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?
(2) Adding a D-specific linker script to binutils?
(3) LTO in GCC/binutils?

(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.

Anyway, please let me know what the plan is, and if there is anything I might be able to do to move it forward.

Mike

Am Sun, 30 Nov 2014 01:52:57 +0000
schrieb "Mike" <none@none.com>:

> This has been brought up before:
> [1]
> http://forum.dlang.org/post/cqzazaqxpwezignixuds@forum.dlang.org
> [2]
> http://forum.dlang.org/post/zapxhodqmotriapuefvm@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.

> 
> Anyway, please let me know what the plan is, and if there is anything I might be able to do to move it forward.
> 
> Mike

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" <none@none.com>:
>
> > This has been brought up before:
> > [1]
> > http://forum.dlang.org/post/cqzazaqxpwezignixuds@forum.dlang.org
> > [2]
> > http://forum.dlang.org/post/zapxhodqmotriapuefvm@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).

"Johannes Pfau"  wrote in message news:m5enbm$2t0e$1@digitalmars.com...

> 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.

And in theory that C++ support (or the C support) can be abused to prevent moduleinfo stripping by adding dummy references to the moduleinfo from .ctors sections, forcing it to be linked in.