[Bug find-debuginfo/33992] New: find-debuginfo script: processing large .a archives is extremely slow despite -j

arekm at maven dot pl sourceware-bugzilla@sourceware.org
Mon Mar 16 10:08:54 GMT 2026


https://sourceware.org/bugzilla/show_bug.cgi?id=33992

            Bug ID: 33992
           Summary: find-debuginfo script: processing large .a archives is
                    extremely slow despite -j
           Product: debugedit
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: find-debuginfo
          Assignee: unassigned at sourceware dot org
          Reporter: arekm at maven dot pl
                CC: debugedit at sourceware dot org
  Target Milestone: ---

debugedit 5.3

find-debuginfo script takes 17+ minutes to process libint2.a (985x .o, 279MB)
on a 28- core machine. The -j flag - no effect - parallelism seem to only apply
across top-level files, not within a single archive.

do_ar_file() serializes debugedit runs. The while-read loop in do_ar_file()
calls debugedit on each extracted .o one at a time. At ~1s per call, 985
members = ~16 minutes, everythin serialized.

n_jobs gets clamped to the number of primary files before do_ar_file() is ever
called (n_jobs=$n_files). Is set to only 2 when a package ships just one .so
and one .a.

Possible fix: split the loop into 3 phases - extract-all,
debugedit-all-in-parallel, rebuild-in-order, using xargs -P  (debugedit using
max -j allowed). The -l SOURCEFILE output per-member files to avoid concurrent
writes, then merged.

And there is also issue with ar rebuilding.

Reproduction - a large static library containing hundreds of .o files with
debug info - in my case it was libint2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Debugedit mailing list