Jump to page: 1 2 3
Thread overview
[Issue 879] support for --gc-sections
May 23, 2014
Martin Nowak
May 25, 2014
Martin Nowak
May 27, 2014
Martin Nowak
May 27, 2014
Orvid King
May 27, 2014
Martin Nowak
May 28, 2014
Martin Nowak
Jul 04, 2014
Martin Nowak
Jul 04, 2014
David Nadlinger
Jul 04, 2014
Martin Nowak
Jul 04, 2014
Martin Nowak
Jul 04, 2014
David Nadlinger
Jul 05, 2014
Martin Nowak
Jul 05, 2014
Martin Nowak
Jul 05, 2014
David Nadlinger
Jul 09, 2014
David Nadlinger
Jul 09, 2014
David Nadlinger
Jul 29, 2014
JR
Feb 01, 2016
Marco Leise
May 09, 2016
Walter Bright
Apr 02, 2017
Marco Leise
Apr 02, 2017
David Nadlinger
Apr 03, 2017
Marco Leise
Apr 03, 2017
David Nadlinger
Apr 03, 2017
ZombineDev
Jul 13, 2019
RazvanN
May 23, 2014
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
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
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
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
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
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
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
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
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
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.

--
« First   ‹ Prev
1 2 3