• Mike (18/18) Nov 29 2014 This has been brought up before:
• Johannes Pfau (14/36) Nov 30 2014 AFAIK that's almost impossible. You can't replicate the complete linker
• Iain Buclaw via D.gnu (4/35) Nov 30 2014 To contrast with another young language. Go/Android has linker support i...
• Daniel Murphy (4/9) Dec 01 2014 And in theory that C++ support (or the C support) can be abused to preve...

"Mike" <none none.com> writes:

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

Johannes Pfau <nospam example.com> writes:

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

"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:

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

"Daniel Murphy" <yebbliesnospam gmail.com> writes:

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