help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exorbitant link times with debugging info


From: Bernd Strieder
Subject: Re: Exorbitant link times with debugging info
Date: Fri, 09 Feb 2007 14:51:32 +0100
User-agent: KNode/0.10.1

Hello,

I wrote:
> for some years I've been running into problems with exorbitant link
> times from time to time with different g++ and binutils releases.
> Sometimes just switching either binutils or g++ to e.g. a self-built
> one solved the problem. Now that I've been running into it again, I
> decided to find the cause.
>[...]
> I do not have an idea, what I can do to make sure, that a toolchain
> will not have those long link times. What options do I have to build
> gcc or binutils or my code with to avoid it? That's the question I'm
> posting for.

A partial answer is here

http://sourceware.org/ml/binutils/2006-08/msg00334.html

Indeed, using a recent snapshot of binutils provides the fastest linking
time I have seen ever. There is no official release including the
patch, yet.

During configuration gcc finds out a few things about ld, among them
some COMDAT section settings.

When building gcc-4.1.2-20070129, it found out that my system linker
does not support COMDAT sections, so gcc switches to .gnu.linkonce.t,
which makes a fast link in this combination. That was the fast link in
my first posting.

When building gcc-4.1.2-20070129 against the latest official binutils
release, COMDAT sections are supported, and due to the patch from above
missing, linking is slow with those binutils.

My system gcc is compiled with COMDAT section support, but the system
linker is not and obviously falls back to slow mode on object files
with comdat sections. This lead to the slow link in my first posting.

The snapshot binutils seem to make the fastest out of it, whenever they
get used, but at the cost of a some 30% bigger binary. 

And I need not wonder, why there are so few answers, this is deep in
active development of binutils and gcc. There are quite some problems
open, e.g. how to handle debug information correctly and efficiently,
and it is only due to hacks, that the situation is bearable. As always,
it is no bad idea to keep an eye on the latest (snapshot) releases.

Bernd Strieder



reply via email to

[Prev in Thread] Current Thread [Next in Thread]