Bug 21033

Summary: Large (C++) debug libraries using COFF linker take large amounts of time to build (30 minutes)
Product: binutils Reporter: William D. Jones <thor0505>
Component: ldAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: nickc
Priority: P2    
Version: 2.27   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: Profiling information building LTO.dll

Description William D. Jones 2017-01-08 06:33:29 UTC
Created attachment 9743 [details]
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.
Comment 1 Nick Clifton 2024-01-22 12:34:35 UTC
Fixed by commit: 6aadf8a04d162feb2afe3c41f5b36534d661d447