--gc-sections and GDC

Johannes Pfau via D.gnu d.gnu at puremagic.com
Thu Jul 17 12:33:51 PDT 2014


Am Thu, 17 Jul 2014 11:29:56 +0000
schrieb "David Nadlinger" <code at klickverbot.at>:

> On Wednesday, 16 July 2014 at 20:05:37 UTC, Johannes Pfau wrote:
> > 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.
> 
> Instead of a fully custom linker script, I'd go for extending the 
> existing one using the INSERT AFTER/BEFORE commands. This way, 
> there should be less potential for breaking any weird 
> system-specific stuff. Within limits, such a script would also 
> work fine with any custom scripts some weird C libraries might be 
> using.

My idea is actually different: Instead of working against the standard
linker scripts, I'll modify these to support D. They already have C++
specific support, the D support can be added in some way which leaves
non-D programs completely unaffected and the binutils maintainers have
been cooperative before when Iain added D support to binutils.

So I'll first finish some proof of concept, then ask on the binutils
mailing list if they'd accept D specific changes. Then ask you guys to
make sure we have a solution for all compilers and the finally provide
a patch for binutils.
> 
> But still, the problem of making this transparent to the user 
> remains. There is a bit of trickery you can do with implicit 
> linker script, but ultimately I couldn't get it to behave nicely, 
> i.e. be consistently linkable using "gcc".

Linking with gcc is impossible, even with modified standard linker
scripts. The reason is you can't bracket the TLS sections with the
linkerscript, you can only tell it to move symbols from certain object
files to the start/end of the section. So you'll always need to pass a
dend.o dstart.o to the linker for shared libraries and the main
application.

I don't think this is a problem, g++ does exactly the same and
therefore suffers from the same problem.
> 
> In the end, this seemed far more troublesome than just working 
> around the problem, especially since you have to make it work on 
> all platforms. Even if you restrict yourself to common x86_64 
> Linux distros, you have to support various versions of both 
> ld.bfd and ld.gold, and the latter doesn't natively use linker 
> scripts (there is an emulation layer, which mostly works, but 
> seemed to behave slightly differently in my tests).
> 
The standard linker scripts are generated from a template. Modify once,
benefit for (almost) all architectures. Only drawback: This will then
of course require a very new binutils version.
Gold should support standard linker scripts, AFAIK. I only use
features also used by the C++ runtime so it has to work ;-) 




More information about the D.gnu mailing list