[Bug ld/21033] New: Large (C++) debug libraries using COFF linker take large amounts of time to build (30 minutes)

[thor0505 at comcast dot net]

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.