Am Wed, 16 Jul 2014 15:35:09 +0100 schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
> On 16 July 2014 15:12, Mike via D.gnu <d.gnu@puremagic.com> wrote: > > On Wednesday, 16 July 2014 at 13:52:57 UTC, Mike wrote: > >> > >> I received a question from Dicebot in at the end of my > >> presentation. He asked about the --gc-sections linker flag > >> breaking code from GDC. > >> > >> I recently discovered how one can see why this is occurring, and I > >> hope this will help identify the problem and lead to a solution. > >> > >> Compile any simple hello world program with the following gcc > >> command: gcc --verbose -Wl,--verbose test.c. > >> > >> Part of the output is GCC's internal linker script as shown > >> below. I believe this is the source of the problem. Here's my > >> theory. > >> > >> D is not C, and is likely generating code that the GCC internal > >> linker script doesn't know about. This code may be incorrectly > >> identified as dead code because there is no 'link' to it and, > >> therefore, appears unused. If D or GDC is generating any code > >> like this, it needs to be marked as KEEP in the linker script. > >> You can see examples of this in GCC's internal linker script below. > >> > >> If my theory is correct, GDC may have to make an internal linker > >> script specifically for D's code generation that marks such code > >> as KEEP. > >> > >> I hope I'm not just blowing smoke. > >> > >> Mike > > > > > > And I just checked with GDC... > > gdc --verbose -Wl,--verbose test.d > > > > ... and the internal linker script is exactly the same as the C > > version. That doesn't seem right to me. I would expect them to be > > at least a little different. > > > > Mike > > Using a D-specific linker script in is outside the scope of GDC > itself. I'd have to make a patch to Binutils. > > And yes, a bespoke linker script would solve many problems that are > currently managed by the compiler. > > Regards > Iain Please don't start working on a D specific linker script, cause I'm already working on that ;-) I've only done moduleinfo so far, but TLS is next, then shared library support.