[Issue 879] support for --gc-sections

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

RazvanN  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #29 from RazvanN  ---
I haven't been able to reproduce any of the issues posted. It seems that this
issue has been fixed. Closing as WORKSFORME. Please reopen if you find any
other issues.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #28 from David Nadlinger  ---
(In reply to Marco Leise from comment #27)
> I extended the 1x1 test matrix by a static Phobos library on one axis and
> ld.bfd on the other and found that in all 4 cases dub greets me with the
> expected "Neither a package ..." message.
> (I used dmd and Phobos in version 2.073.2 and binutils-2.26.1 on Gentoo.)

That's quite promising already. From what it took to get --gc-sections working
on LDC it would be a minor miracle if it suddenly started working on DMD as
well (unless we have been slowly porting over the required changes by
accident). This is also the reason why I asked about different configurations;
this is not just a "normal" backend issue, but the druntime module registration
code is heavily affected by a few --gc-sections linker bugs/peculiarities. When
implementing this on LDC, I only found out about the bigger part of the issues
when pushing the changes to CI resp. from user reports in the subsequent beta.

If the flag really works on DMD now, it would be nice to enable it by default
to drastically reduce binary sizes (LDC has been shipping with --gc-sections on
for a couple of releases now). Building the test suite on the different CI
systems and having people test it during pre-release would be a good stress
test as well.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #27 from Marco Leise  ---
Shame on me, I only tested with ld.gold and shared Phobos library. I extended
the 1x1 test matrix by a static Phobos library on one axis and ld.bfd on the
other and found that in all 4 cases dub greets me with the expected "Neither a
package ..." message.
(I used dmd and Phobos in version 2.073.2 and binutils-2.26.1 on Gentoo.)

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #26 from David Nadlinger  ---
(In reply to Marco Leise from comment #25)
> I haven't thoroughly tested it, but at least dub works with --gc-sections
> since - I believe - dmd-2.072. So from my side this issue can be closed.

Are you sure it works with both ld.bfd and ld.gold and against a static as well
as shared runtime? This should be the minimum set of tests before considering
this closed, although the set of linker bugs also differs between the various
distros (i.e. linker versions) out there.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #25 from Marco Leise  ---
I haven't thoroughly tested it, but at least dub works with --gc-sections since
- I believe - dmd-2.072. So from my side this issue can be closed.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #24 from Walter Bright  ---
DMD on Linux/Elf/OSX now uses Dwarf exception handling info, so the deh
sections are no longer an issue.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #23 from Marco Leise  ---
Issue persists with dmd-2.070 on amd64. For example compiling dub fails.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

JR zor...@gmail.com changed:

   What|Removed |Added

 CC||zor...@gmail.com

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

David Nadlinger c...@klickverbot.at changed:

   What|Removed |Added

   Keywords|pull|

--- Comment #21 from David Nadlinger c...@klickverbot.at ---
There is an additional complication: ld.bfd turns __bss_start/_end into local
symbols when passing --gc-sections. This breaks the module collision check in
druntime, as discussed here:
http://forum.dlang.org/post/ferkvfamznsuhonok...@forum.dlang.org. The linked
discussion is about LDC in particular, but from a few preliminary tests, DMD
also seems to be affected.

The root cause for this behavior seems to be this change in binutils 2.19:
https://sourceware.org/bugzilla/show_bug.cgi?id=13683. It's hard to tell
whether this is a bug in ld or not, but either way we'll have to live with it.

ld.gold is not affected.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #22 from David Nadlinger c...@klickverbot.at ---
(In reply to David Nadlinger from comment #21)
 There is an additional complication: ld.bfd turns __bss_start/_end into
 local symbols when passing --gc-sections. […]

LDC now uses special weak symbols, strongly defined in the D entry point
module, to avoid this problem altogether:

https://github.com/ldc-developers/druntime/commit/f57df3f586ba445b94b167106f82a807c0f1738e
https://github.com/ldc-developers/ldc/commit/4abdec752eed1d8eeff116251fdf8c3733927704

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #18 from Martin Nowak c...@dawg.eu ---
(In reply to David Nadlinger from comment #17)
 I was under the impression that --gc-sections indeed does this when linking
 an executable. Default visibility on its own is not enough to keep a symbol
 (and thus its section) alive, unless it is required to resolve an undefined
 symbol from a linked shared object. Maybe we have a different understanding
 of what an exported symbol is, though.

Right, gc-sections doesn't care about visibility, but the ModuleInfos are not
emitted to individual sections (.rodata or .text) so they won't get removed
unless they are the only symbols in .rodata/.text.

 (In reply to Martin Nowak from comment #16)
  Another problem that I have is that ld.gold with --gc-sections doesn't copy 
  the .minfo_beg/.minfo_end sections from an archive object, so it breaks the 
  section brackets even when all .minfo* sections are pinned.
 
 What precisely do you refer to as archive object? An object file pulled in
 from a static library?

Yes, object files from an archive. It's probably the same for normal objects.
With --gc-sections the ld.gold linker seems to only copy sections that contain
referenced symbols. I can also reference .minfo_beg/.minfo/.minfo_end in each
ctor, but for some reason the order for the output sections isn't preserved.

 On Linux x86_64, our static release-mode binaries
 are on average 1/4 the size of DMD's for small programs now

Interesting, dmd uses a section per function by default, but for unknown
reasons --gc-sections doesn't have a huge effect.
https://github.com/D-Programming-Language/dmd/pull/3597#issuecomment-44671223

I'd like to give the linker as good information as possible. For example when a
functions isn't used the linker should strip the associated EH data. Likewise
ModuleInfo is needed only when any data or function of a module end up in a
DSO.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #19 from Martin Nowak c...@dawg.eu ---
(In reply to Martin Nowak from comment #18)
 I can also reference .minfo_beg/.minfo/.minfo_end in each ctor.

Actually this doesn't work with ld.gold because dmd only uses a single ctor per
DSO (COMDAT) and ld.gold will merge the ctors before checking their references.
So I only end up with the .minfo* sections of the first object file.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #13 from Martin Nowak c...@dawg.eu ---
The R_arch_NONE solution of pinning the .deh_eh and .minfo sections in the
d_dso_init function doesn't work with ld.gold because the gold linker removes
sections before dragging in object files from an archive whereas the bfd linker
removes sections after copying all input sections to the output sections.
For ld.gold one would need to pin the .deh_beg/.deh_eh/.deh_end and the
.minfo_beg/.minfo/.minfo_end sections in every object file of an archive.
At best the pinning would be done from the associated symbol (e.g. function for
.deh and ModuleInfo for .minfo).

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

David Nadlinger c...@klickverbot.at changed:

   What|Removed |Added

 CC||c...@klickverbot.at

--- Comment #14 from David Nadlinger c...@klickverbot.at ---
I don't see how pinning the ModuleInfo  reference from the ModuleInfo itself
would work, as there might not be any direct references to the ModuleInfo. In
fact, unless your module makes calls to _d_array_bounds or so, it's even rather
unlikely that such a reference that would keep the ModuleInfo alive exists.
Thus, the global ctor needs to keep the ModuleInfo alive (via the .minfo ref),
not the other way round.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #15 from Martin Nowak c...@dawg.eu ---
(In reply to David Nadlinger from comment #14)
 I don't see how pinning the ModuleInfo  reference from the ModuleInfo itself
 would work, as there might not be any direct references to the ModuleInfo.
 In fact, unless your module makes calls to _d_array_bounds or so, it's even
 rather unlikely that such a reference that would keep the ModuleInfo alive
 exists. Thus, the global ctor needs to keep the ModuleInfo alive (via the
 .minfo ref), not the other way round.

ModuleInfos are exported global symbols, so the linker should not remove them.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #16 from Martin Nowak c...@dawg.eu ---
Another problem that I have is that ld.gold with --gc-sections doesn't copy the
.minfo_beg/.minfo_end sections from an archive object, so it breaks the section
brackets even when all .minfo* sections are pinned.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #17 from David Nadlinger c...@klickverbot.at ---
(In reply to Martin Nowak from comment #15)
 ModuleInfos are exported global symbols, so the linker should not remove
 them.

I was under the impression that --gc-sections indeed does this when linking an
executable. Default visibility on its own is not enough to keep a symbol (and
thus its section) alive, unless it is required to resolve an undefined symbol
from a linked shared object. Maybe we have a different understanding of what an
exported symbol is, though.

(In reply to Martin Nowak from comment #16)
 Another problem that I have is that ld.gold with --gc-sections doesn't copy 
 the .minfo_beg/.minfo_end sections from an archive object, so it breaks the 
 section brackets even when all .minfo* sections are pinned.

What precisely do you refer to as archive object? An object file pulled in
from a static library? As we discussed a while ago, for LDC I currently emit
one unique global ctor per object file (as we emit one section per text/data
symbol like -ffunction-sections, this is not quite as bad as it maybe would be
for dmd -lib, even though still a bit wasteful). As .ctors are roots for the
linker's live section graph, I can conveniently pin the bracketing symbols as
well as the ModuleInfo reference itself that way.

The whole design was purely a workaround for LLVM bugs/limitations, but it
lead to LDC passing the test suite [*] using both ld.bfd and ld.gold without
too much effort. As mentioned above, LDC currently generates quite a bit of
cruft in the executable due to unneeded symbols in .minfo_beg/.minfo_end and
all the duplicate global ctors, but it's still better than not being able to
use --gc-sections at all. On Linux x86_64, our static release-mode binaries are
on average 1/4 the size of DMD's for small programs now (Git master vs. Git
master, which isn't entirely fair because we are still on 2.065, of course).


[*] Except for the module conflict check in druntime being broken due to copy
relocations.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

   Keywords||pull

--- Comment #10 from Martin Nowak c...@dawg.eu ---
OK, group sections didn't work out too well, so I just added fake references to
the .deh_eh and .minfo sections in the dso startup code.
https://github.com/D-Programming-Language/dmd/pull/3597

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

Orvid King blah38...@gmail.com changed:

   What|Removed |Added

 CC||blah38...@gmail.com

--- Comment #11 from Orvid King blah38...@gmail.com ---
It would also be nice if a dmd equivalent of -fdata-sections and
-ffunction-sections was supported by dmd, but the issue with that is quite
simple; optlink.

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #12 from Martin Nowak c...@dawg.eu ---
(In reply to Orvid King from comment #11)
 It would also be nice if a dmd equivalent of -fdata-sections and
 -ffunction-sections was supported by dmd, but the issue with that is quite
 simple; optlink.

If you build a -lib, then the compiler will put every symbol into it's own
object.
This is a linux bug, so it's the wrong place for an optlink rant ;).

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

--- Comment #9 from Martin Nowak c...@dawg.eu ---
It should be possible to put the EH tables and ModuleInfos into section groups,
so the linker wouldn't dismiss them even though they aren't referenced
explicitly.
http://docs.oracle.com/cd/E19683-01/816-1386/chapter7-26/index.html

--

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=879

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 CC||c...@dawg.eu
   Assignee|nob...@puremagic.com|c...@dawg.eu

--- Comment #8 from Martin Nowak c...@dawg.eu ---
There is a potential to reduce the binary size and gain speedups from this.

--

[Issue 879] support for --gc-sections

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=879


Trass3r mrmoc...@gmx.de changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||mrmoc...@gmx.de
   Platform|x86 |All
Version|1.00|D1  D2
   Severity|enhancement |normal


--- Comment #6 from Trass3r mrmoc...@gmx.de 2013-07-23 11:26:15 CEST ---
--gc-sections breaks everything, even hello world.

import std.stdio;
void main()
{
writefln(FIXME!);
}

$ dmd -L--gc-sections -L--print-gc-sections test.d
ld: Removing unused section '.deh_eh' in file 'test.o'
ld: Removing unused section '.minfo' in file 'test.o'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__34_85a.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__54_915.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__5a_ff3.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__5e_8d3.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__60_fb1.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__62_882.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__63_f60.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(dmain2_44e_47b.o)'
ld: Removing unused section '.deh_eh' in file 'libphobos2.a(dmain2_44e_47b.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_455_482.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_462_7db.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_467_46f.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_475_60d.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_478_6c8.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_47b_4cd.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_47c_53b.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_480_2a1.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(sections_linux.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__4db_e8d.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(console.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(container.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__551_86e.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(array.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(conv.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(exception.o)'
ld: Removing unused section '.minfo' in file
'libphobos2.a(exception_599_8af.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(format.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(functional.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(math.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(range.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(stdio.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(stdio_c2b_180.o)'
ld: Removing unused section '.deh_eh' in file 'libphobos2.a(stdio_c2b_180.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(stdiobase.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(string.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(traits.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(typecons.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(typetuple.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(utf.o)'
ld: Removing unused section '.deh_eh' in file 'libphobos2.a(object__6_32e.o)'
ld: Removing unused section '.deh_eh' in file 'libphobos2.a(object__1b_3a8.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__57_ef0.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(runtime_e3_76e.o)'
ld: Removing unused section '.deh_eh' in file 'libphobos2.a(runtime_e3_76e.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(thread_12d_5a0.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(gc.o)'
ld: Removing unused section '.deh_eh' in file 'libphobos2.a(gcx_2f3_8a.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(deh2.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(object__434_e4b.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(dmain2.o)'
ld: Removing unused section '.minfo' in file 'libphobos2.a(lifetime.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_459_856.o)'
ld: Removing unused section '.deh_eh' in file
'libphobos2.a(lifetime_459_856.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_45e_4a3.o)'
ld: Removing unused section '.data' in file 'libphobos2.a(lifetime_461_4e2.o)'
ld: 

[Issue 879] support for --gc-sections

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=879



--- Comment #7 from Trass3r mrmoc...@gmx.de 2013-07-23 11:28:14 CEST ---
As far as I remember the flag works fine with gdc.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 879] support for --gc-sections

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=879


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

 CC||nfx...@gmail.com


--- Comment #5 from Brad Roberts bra...@puremagic.com 2010-08-29 12:35:37 PDT 
---
*** Issue 4758 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---