Bug 32760 - debugedit should handle .a static ar archive
Summary: debugedit should handle .a static ar archive
Status: RESOLVED FIXED
Alias: None
Product: debugedit
Classification: Unclassified
Component: debugedit (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Frank Ch. Eigler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-04 15:49 UTC by Mark Wielaard
Modified: 2025-07-29 08:05 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
Project(s) to access:
ssh public key:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Wielaard 2025-03-04 15:49:07 UTC
An static .a ar archive is a collection of .o object files used for static linking. debugedit should be able to rewrite the debuginfo file/path strings inside those.

Filed under debugedit, but could be implemented in find-debuginfo by simply ar x .a; run debugedit on all .o files; ar m all files.
Comment 2 Frank Ch. Eigler 2025-06-18 18:44:43 UTC
commit eaf5bfc1a67652530efc2a2037ca80ec63aba0f8
Author: Frank Ch. Eigler <fche@redhat.com>
Date:   Wed Jun 18 14:40:59 2025 -0400

    PR32760: find-debuginfo: handle static libraries
    
    Formerly, static .a libraries with debuginfo were ignored by
    find-debuginfo.  If unstripped, then the raw build-directory paths in
    them would leak into the downstream package.  New code in
    find-debuginfo looks for archive ".a" files in the build tree, and
    runs debugedit only to enumerate and rewrite source paths.  This
    allows ultimate users of the .a files to link in object files with all
    the debuginfo, except with usable (and debuginfod-resolvable) source
    file paths.
    
    This works by having find-debuginfo find .a files, extracting all
    the .o files one at a time, running debugedit, then repacking the
    files back into the .a.  do_file() delegates to do_ar_file(),
    doing rather less work than for .so/exec files.
    
    New autotest case covers duplicate-member-name functionality,
    including with cruelly whitespace named members.  Defaults off
    & skips testing unless ar support "O" (binutils > v2.31).
    
    Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
Comment 3 Funda Wang 2025-07-28 08:17:24 UTC
Well, such a change increases build time significantly.

Take openbals as an example, 4 hours [1] vs 43 hours [2]

May it be turned off?

[1]: https://koji.fedoraproject.org/koji/taskinfo?taskID=128532835
[2]: https://koji.fedoraproject.org/koji/taskinfo?taskID=135240890
Comment 4 Mark Wielaard 2025-07-28 10:07:16 UTC
(In reply to Funda Wang from comment #3)
> Well, such a change increases build time significantly.
> Take openbals as an example, 4 hours [1] vs 43 hours [2]

An increase of 10 times seems indeed significant.
Currently on the road and cannot easily download those logs.
But will investigate where all the times goes when I am back home.

> May it be turned off?

Yes. Invoke find-debuginfo with --no-ar-files

  If --no-ar-files is given, then static libraries will be ignored.  Otherwise,
  they receive only with source-path rewriting and collection.  They are
  not stripped, since they have no persistent build-ids to accommodate
  eventual reunification.

Your distro might also have build macros to make that happen.
Comment 5 Funda Wang 2025-07-28 10:17:39 UTC
You do not need to download the build log, as the build.log does not record time of every step.

In my test on my local machine, the find-debuginfo just hangs at find-debuginfo for over two hours. With debuginfo 5.1, it just take about 1.5 hours to finish the whole build. So I guess there must be some important change here.
Comment 6 Frank Ch. Eigler 2025-07-28 11:39:19 UTC
The official fedora way of turning off this function is to add

%undefine _preserve_static_debuginfo

into your spec.

But for this to be responsible for an additional 40 hours of processing seems absurd.  Something very strange must be going on with this build / builder.  I'd recommend trying again first.
Comment 7 Frank Ch. Eigler 2025-07-28 11:50:19 UTC
Another possibility to help diagnose the problem is:

%global __find_debuginfo /bin/time -v /usr/bin/find-debuginfo

so we get a sense of what took so long.
Comment 8 Funda Wang 2025-07-29 08:05:03 UTC
> Invoke find-debuginfo with --no-ar-files
Thanks. After defining _find_debuginfo_opts locally:

%global _find_debuginfo_opts --no-ar-files

The whole build finished as usally, for about 1.5 hours.