[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Exorbitant link times with debugging info
From: |
Bernd Strieder |
Subject: |
Exorbitant link times with debugging info |
Date: |
Thu, 08 Feb 2007 12:39:35 +0100 |
User-agent: |
KNode/0.10.1 |
Hello,
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.
The full debug build of the app I'm working on has some 90MB size. Using
the compiler as distributed with the system I'm working on gcc 4.1.0 as
of openSuSE 10.1, the link time is some 5 minutes. Using prerelease
4.1.2-20070129, the link time is 10 seconds.
When looking at the assembly generated, the most significant difference
is, that in the slowly linked files many symbols are
.section .text.<whatever>,comdat
while in the fastly linked files most of the symbols are
.section .gnu.linkonce.t.<whatever>,"ax",@progbits
I found a few references via google on the question of comparing binary
code of functions byte by byte to merge them and optimizing this, so I
think I have an idea, where the differences in link times come from in
the end. If there are nice references explaining that field of
problems, or at least some sensible keywords for googling, please feel
free to post them.
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.
Thanks,
Bernd Strieder
- Exorbitant link times with debugging info,
Bernd Strieder <=