[Issue 879] support for --gc-sections
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
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
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
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
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
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
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
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
https://issues.dlang.org/show_bug.cgi?id=879 Andrei Alexandrescu changed: What|Removed |Added Version|D1 & D2 |D2 --
[Issue 879] support for --gc-sections
https://issues.dlang.org/show_bug.cgi?id=879 JR changed: What|Removed |Added CC||zor...@gmail.com --
[Issue 879] support for --gc-sections
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #22 from David Nadlinger --- (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
https://issues.dlang.org/show_bug.cgi?id=879 David Nadlinger changed: What|Removed |Added Keywords|pull| --- Comment #21 from David Nadlinger --- 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
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #20 from David Nadlinger --- (In reply to Martin Nowak from comment #19) > 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. This was the reason for me to switch to emitting one ctor per module (due to an LLVM implementation quirk, the situation was a bit different and I already ran into this problem with ld.bfd, but it was more or less the same). Of course, it's an ugly and hacky approach, but it seems to work for now. The more beautiful option (doesn't apply to the pin-required-EH-tables-from-function, of course) seems to be to use a custom linker script for generating the bracketing symbols as well as KEEP()ing the .minfo section. Because of INSERT and implicit linker scripts, this probably could be made to work, but ensuring that this also works with ld.gold and doesn't break any user expectations was a can of worms I decided not to open just yet. --
[Issue 879] support for --gc-sections
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #19 from Martin Nowak --- (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
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #18 from Martin Nowak --- (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
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #17 from David Nadlinger --- (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
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #16 from Martin Nowak --- 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
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #15 from Martin Nowak --- (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
https://issues.dlang.org/show_bug.cgi?id=879 David Nadlinger changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #14 from David Nadlinger --- 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
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #13 from Martin Nowak --- 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
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 879] support for --gc-sections
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #12 from Martin Nowak --- (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
https://issues.dlang.org/show_bug.cgi?id=879 Orvid King changed: What|Removed |Added CC||blah38...@gmail.com --- Comment #11 from Orvid King --- 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
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak changed: What|Removed |Added Keywords||pull --- Comment #10 from Martin Nowak --- 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
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #9 from Martin Nowak --- 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
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu Assignee|nob...@puremagic.com|c...@dawg.eu --- Comment #8 from Martin Nowak --- There is a potential to reduce the binary size and gain speedups from this. --
[Issue 879] support for --gc-sections
http://d.puremagic.com/issues/show_bug.cgi?id=879 --- Comment #7 from Trass3r 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
http://d.puremagic.com/issues/show_bug.cgi?id=879
Trass3r 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 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: Removing unused section '.da
[Issue 879] support for --gc-sections
http://d.puremagic.com/issues/show_bug.cgi?id=879 Brad Roberts changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #5 from Brad Roberts 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: ---
