This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Very slow link times on debug versions of C++ program on x86_64. Includes oprofile of ld...
- From: "Talbot, George" <Gtalbot at locuspharma dot com>
- To: <binutils at sourceware dot org>
- Date: Wed, 20 Jun 2007 09:19:39 -0400
- Subject: Very slow link times on debug versions of C++ program on x86_64. Includes oprofile of ld...
Hi all,
I've recently upgraded my machine here to an x86_64 box running Fedora
Core 6 (7 came out a week after I installed doh!). I have a largish C++
program that I compile in both a release (-O3 -DNDEBUG) and debug (-O0
-ggdb3) versions that uses a lot of templates and stuff. Linking the
release one is pretty quick...on the order of 10-20 seconds or so.
However linking the debug version takes many minutes, and the CPU is
pegged during the link.
FYI:
[gtalbot@germanium testsrc]$ gcc --version
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
[gtalbot@germanium testsrc]$ ld --version
GNU ld version 2.17.50.0.6-2 20061020
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License. This program has absolutely no
warranty.
This has been driving me crazy, so I downloaded the source RPM, and
built ld with "-g" turned on, installed it, then linked my program with
oprofile running. Here's the output:
CPU: AMD64 processors, speed 1000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
unit mask of 0x00 (No unit mask) count 100000
samples % symbol name
40486 49.3870 match_simple_wild
18375 22.4148 walk_wild_section_specs3_wild2
12473 15.2152 walk_wild_section_general
2536 3.0936 walk_wild_section_specs2_wild1
2483 3.0289 walk_wild_section_specs1_wild1
1347 1.6431 lang_size_sections_1
729 0.8893 lang_process
654 0.7978 walk_wild_section_specs4_wild2
413 0.5038 lang_do_assignments_1
358 0.4367 lang_add_section
318 0.3879 walk_wild
279 0.3403 walk_wild_consider_section
245 0.2989 insert_pad
239 0.2915 find_section
161 0.1964 ldlang_add_file
149 0.1818 stat_alloc
103 0.1256 lang_for_each_statement_worker
70 0.0854 section_already_linked
68 0.0830 build_link_order
64 0.0781 .plt
64 0.0781 new_statement
63 0.0769 walk_wild_file
57 0.0695 output_section_callback
34 0.0415 gldelf_x86_64_check_needed
30 0.0366 unique_section_p
27 0.0329 lang_one_common
25 0.0305 gldelf_x86_64_find_statement_assignment
24 0.0293 gldelf_x86_64_stat_needed
20 0.0244 lang_for_each_input_file
16 0.0195 walk_wild_section_specs1_wild0
13 0.0159 lang_statement_append
10 0.0122 gldelf_x86_64_vercheck
6 0.0073 walk_wild_section
5 0.0061 yyparse
4 0.0049 open_input_bfds
3 0.0037 gldelf_x86_64_after_open
3 0.0037 ldfile_open_file
3 0.0037 section_iterator_callback
3 0.0037 yylex
2 0.0024 gc_section_callback
2 0.0024 gldelf_x86_64_place_orphan
2 0.0024 lang_add_wild
2 0.0024 ldfile_try_open_bfd
2 0.0024 map_input_to_output_sections
1 0.0012 exp_fold_tree_1
1 0.0012 gldelf_x86_64_load_symbols
1 0.0012 gldelf_x86_64_parse_ld_so_conf
1 0.0012 gldelf_x86_64_search_needed
1 0.0012 gldelf_x86_64_try_needed
1 0.0012 input
1 0.0012 ldfile_open_file_search
Can anyone tell me what's going on here? Is there a patch I can apply?
Is there some other option I can pass to either ld or gcc?
Thanks.
--
George T. Talbot
<gtalbot@locuspharma.com>