https://sourceware.org/bugzilla/show_bug.cgi?id=21033
Bug ID: 21033
Summary: Large (C++) debug libraries using COFF linker take
large amounts of time to build (30 minutes)
Product: binutils
Version: 2.27
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: thor0505 at comcast dot net
Target Milestone: ---
Created attachment 9743
--> https://sourceware.org/bugzilla/attachment.cgi?id=9743&action=edit
Profiling information building LTO.dll
Overview: While building a debug build of LLVM 3.9 using the MinGW64 toolchain,
I noticed that libraries/binaries which require large amounts of debug
information take excruciatingly long to build- on the order of 30 minutes or
more.
Even when taking the lack of debug fission (and lack of gold) for the COFF
linker, I am assuming that 30 minute link times are abnormal behavior.
Many of the LLVM libraries and binaries late in the build exhibit these long
link times. For the purposes of this bug report, I will be linking LTO.dll. All
of LTO.dll's constituent libraries and objects were build with debug
information.
Procedure: The exact procedure, including ./configure/cmake command lines, and
caveats, is here:
https://gist.github.com/cr1901/34880b393fff05171cb1cafec49a5228
A quick procedure is to compile LLVM 3.9 using the Debug build type,
specifically the "bin/LTO.dll" target (this requires a Windows machine). The
final LTO.dll link takes 30 minutes to build.
Expected Results: Link times on the order of 2-5 minutes (longer than gold
linking ELF objects, but much shorter than Actual Results).
Actual Results: LTO.dll takes 30 minutes or more to link.
Build Date & Hardware: Built 1-8-2017 on Windows 7 Professional 64-bit, using a
64-bit ld with patches from MINGW-packages on Github. See exact procedure.
Additional Builds and Platforms: Pathological build times do not occur on the
32-bit linker provided from MSYS2 packages.
Additional Information: I have attached profiling information from linking
bin/LTO.dll using the command-line provided in the full reproduction
instructions. Many functions are classified as <spontaneous> by gprof,
including the function most contributing to the build time
(gld_i386pep_place_orphan). Some profile information appears to be missing. are
the -pg command-line options not passed to autogenerated files during the
binutils build? Is there a procedure to enable it for these files?
As I recall, gld_i386pep_place_orphan is one symbol defined in a shell script
snippet that outputs a C source file.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
