[Bug binutils/32238] New: Bug found in binutils version '2.36' with function 'lang_output_section_statement_lookup'

[kumar.naveen099 at gmail dot com]

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.