[Bug binutils/32238] Performance issues found from binutils version '2.36' version while usage of function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #12 from Naveen Kumar --- Were you able to reproduce the issue ? Since all debug flavor builds has to be disabled due to this issue. Just want to check if you were able to repro this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #10 from Naveen Kumar --- Any update? Please let me know if you need anything from me. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 Naveen Kumar changed: What|Removed |Added Severity|normal |critical Priority|P2 |P1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found with binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #3 from Naveen Kumar --- (In reply to Sam James from comment #1) > Can you reproduce it on trunk or 2.43.1? > > A testcase would be appreciated if possible. Yes, on 2.43.1 as well we are noticing this issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #7 from Naveen Kumar --- Host & Target: x86_64 I've been able to repro a ~10x slowdown between 2.29 and 2.36 using open-source LLVM. 1) Download LLVM 19.1.0 sources from https://github.com/llvm/llvm-project/releases/download/llvmorg-19.1.0/llvm-project-19.1.0.src.tar.xz 2) Unarchive and configure with: cmake -DCMAKE_BUILD_TYPE=Debug -G Ninja -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_INSTALL_PREFIX=/path/to/install/dir -DCMAKE_C_FLAGS="-ffunction-sections -fdata-sections" -DCMAKE_CXX_FLAGS="-ffunction-sections -fdata-sections" /llvm-project-19.1.0.src/llvm => This is the folder path where we do unarchive of 'llvm-project-19.1.0.src.tar.xz' file. 3) Build with command: ninja install 4) copy attached main.cpp & Makefile at /llvm-project-19.1.0.src folder 5) Modify the Makefile: => 'LLVM_CONFIG' variable to point to your installed 'llvm-config' utility. => 'LD' variable to point to 2.34 ld version. 6) run the command 'make' and record the build time => if you notice any compiler issues, Please add '-std=c++17' to 'CFLAGS' and rerun 'make' command. 7) Rerun with another ld version (anything b/w 2.36 to 2.42) to observe build time difference (delete main.o first). At 6th step, You can find the linker command in the log where you can see all the flags we are using. Note:- The main.cpp source is taken from an LLVM example, modifying to include some extra stuff, meaning extra required LLVM symbols. Build time metrics: ld 2.34.1-64: real1m25.619s user1m20.950s sys 0m4.287s ld 2.36.1-64: real13m23.851s user13m19.463s sys 0m4.268s perf metrics while running culprit linker (2.36) process:- Samples: 3M of event 'cycles', Event count (approx.): 4629795486714 Children Self Command Shared Object Symbol + 89.25%89.17% ld ld [.] lang_output_section_statement_lookup I hope above repro testcase is sufficient for your use case. BTW, In our original build system we deal with huge set of obj files and linker/ld (> 2.36 version) takes around 65mins to complete. Where as same linker command with ld (< 2.36) will take less than 2mins. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version while usage of function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 Naveen Kumar changed: What|Removed |Added CC||kumar.naveen099 at gmail dot com Summary|Performance issues found|Performance issues found |from binutils version |from binutils version |'2.36' version with |'2.36' version while usage |function|of function |'lang_output_section_statem |'lang_output_section_statem |ent_lookup' |ent_lookup' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #5 from Naveen Kumar --- Created attachment 15728 --> https://sourceware.org/bugzilla/attachment.cgi?id=15728&action=edit main.cpp source file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #6 from Naveen Kumar --- Created attachment 15729 --> https://sourceware.org/bugzilla/attachment.cgi?id=15729&action=edit Makefile to build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #9 from Naveen Kumar --- Created attachment 15730 --> https://sourceware.org/bugzilla/attachment.cgi?id=15730&action=edit main.ii preprocessed file. Please check the attachment for preprocessed main.ii file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 Naveen Kumar changed: What|Removed |Added Summary|Performance issues found|Performance issues found |with binutils version |from binutils version |'2.36' version with |'2.36' version with |function|function |'lang_output_section_statem |'lang_output_section_statem |ent_lookup' |ent_lookup' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] New: Bug found in binutils version '2.36' with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 Bug ID: 32238 Summary: Bug found in binutils version '2.36' with function 'lang_output_section_statement_lookup' Product: binutils Version: 2.36 Status: UNCONFIRMED Severity: critical Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: kumar.naveen099 at gmail dot com Target Milestone: --- We have recently upgraded binutis from 2.29 version to 2.36 and noticed that 'Debug' flavor builds are getting hang for a long time during the linking step. We are following partial linking (ld -r) approach in our build process as mentioned here :- https://stackoverflow.com/questions/29391965/what-is-partial-linking-in-gnu-linker Since we deal with huge source code about 100's of obj files where the static library size is getting huge, To Workaround it we are using partial linking which eliminates a lot of duplication. So we are basically creating a .o file out of a partial linking mechanism and using that .o file to create a '.a' static library. Issue:- With linker (ld) from binutils 2.36 version, Partial linking step is taking around 60 mins to complete for debug flavor builds. We have narrowed down the issue by cloning binutins git repository and performed 'git bisect' to find exact regression causing SHA-ID and noticed that this :- https://github.com/bminor/binutils-gdb/commit/21401fc7bf67dbf73f4a3eda4bcfc58fa4211584 is the regression causing change. The SHA-ID just before the problematic one does not cause any issues where linker(ld) command just finished in 1.5 to 2mins. But the culprit CL that follows is causing the build hangs and linker 'ld' command took nearly 65mins to complete. Here are the more details about debug where i collect a Linux perf of problematic ld process and verify that it's spending most of the extra time in 'lang_output_section_statement_lookup':- Here are the key findings from the perf report: Samples: 15M of event 'cycles', Event count (approx.): 22646358592852 Children Self Command Shared Object Symbol + 96.86%96.80% ld ld [.] lang_output_section_statement_lookup As we can see, both the Children and Self percentages for this function are almost identical, indicating that the function is directly responsible for the majority of the CPU cycles during the linking process. Hence this function is likely causing the hang or performance bottleneck that we are observing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found with binutils version '2.36' version with function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 Naveen Kumar changed: What|Removed |Added Summary|Bug found in binutils |Performance issues found |version '2.36' with |with binutils version |function|'2.36' version with |'lang_output_section_statem |function |ent_lookup' |'lang_output_section_statem ||ent_lookup' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32238] Performance issues found from binutils version '2.36' version while usage of function 'lang_output_section_statement_lookup'
https://sourceware.org/bugzilla/show_bug.cgi?id=32238 --- Comment #13 from Naveen Kumar --- Further looking into the function code ,The behavior of lang_output_section_statement_lookup differs between binutils 2.35 and 2.36. In version 2.35, an if/else guard wraps a do...while loop in the function, but in 2.36 source here: https://github.com/bminor/binutils-gdb/commit/21401fc7bf67dbf73f4a3eda4bcfc58fa4211584, the guard was removed, leaving only an unguarded do...while loop. This change appears to cause continuous looping and delay in the 2.36 linker. We need to see if there is a way to avoid this new behavior. -- You are receiving this mail because: You are on the CC list for the bug.
