https://sourceware.org/bugzilla/show_bug.cgi?id=32237
Bug ID: 32237
Summary: Bug found in binutils version '2.36' with function
'lang_output_section_statement_lookup'
Product: binutils
Version: 2.36
Status: RESOLVED
Severity: critical
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: kumar.naveen099 at gmail dot com
CC: sam at gentoo dot org
Target Milestone: ---
Status: RESOLVED
Resolution: DUPLICATE
CC: sam at gentoo dot org
Hi Team,
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.
Please help take a look.
--- Comment #1 from Sam James <sam at gentoo dot org> ---
Looks the same as PR32238.
*** This bug has been marked as a duplicate of bug 32238 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
