Thread overview | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 23, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak <code@dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code@dawg.eu Assignee|nobody@puremagic.com |code@dawg.eu --- Comment #8 from Martin Nowak <code@dawg.eu> --- There is a potential to reduce the binary size and gain speedups from this. -- |
May 25, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #9 from Martin Nowak <code@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 -- |
May 27, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak <code@dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull --- Comment #10 from Martin Nowak <code@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 -- |
May 27, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 Orvid King <blah38621@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blah38621@gmail.com --- Comment #11 from Orvid King <blah38621@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. -- |
May 27, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #12 from Martin Nowak <code@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 ;). -- |
May 28, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak <code@dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- |
July 04, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 Martin Nowak <code@dawg.eu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #13 from Martin Nowak <code@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). -- |
July 04, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 David Nadlinger <code@klickverbot.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code@klickverbot.at --- Comment #14 from David Nadlinger <code@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. -- |
July 04, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #15 from Martin Nowak <code@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. -- |
July 04, 2014 [Issue 879] support for --gc-sections | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=879 --- Comment #16 from Martin Nowak <code@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. -- |
Copyright © 1999-2021 by the D Language Foundation