[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes

[wcohen at redhat dot com]

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

--- Comment #7 from William Cohen <wcohen at redhat dot com> ---
I rebuilt the binutils-2.39-8.fc38.src.rpm on the f36 machine that I originally
discover merge_gnu_build_note taking a large fraction of the rpmbuild install
and installed the resulting binutils rpms.  The binutils change reduced samples
in merge_gnu_build_note from 70% to 50%.  Overall runtime was 2085 seconds wall
clock time to 1049 seconds, so half of the original.

compared the notes bewteen the system firefox libxul.so and the locally built
one.  There doesn't seem to be crazy differences between them.

[wcohen@haro firefox-108.0.1-3.fc36.x86_64]$ pwd
/home/wcohen/rpmbuild/BUILDROOT/firefox-108.0.1-3.fc36.x86_64
[wcohen@haro firefox-108.0.1-3.fc36.x86_64]$  readelf --notes --wide
/usr/lib64/firefox/libxul.so  > /tmp/orig_xul
readelf: /usr/lib64/firefox/libxul.so: Warning: Gap in build notes detected
from 0xcb7d6f to 0x661aebf
[wcohen@haro firefox-108.0.1-3.fc36.x86_64]$  readelf --notes --wide
usr/lib64/firefox/libxul.so  > /tmp/new_xul
readelf: usr/lib64/firefox/libxul.so: Warning: Gap in build notes detected from
0xcb7d6f to 0x661aebf
[wcohen@haro firefox-108.0.1-3.fc36.x86_64]$ diff -u /tmp/orig_xul /tmp/new_xul 
--- /tmp/orig_xul       2023-01-16 11:40:56.894249366 -0500
+++ /tmp/new_xul        2023-01-16 11:41:07.068311517 -0500
@@ -1,15 +1,15 @@

 Displaying notes found in: .note.gnu.build-id
   Owner                Data size       Description
-  GNU                  0x00000014      NT_GNU_BUILD_ID (unique build ID
bitstring)         Build ID: c71b2c4767cf93aa91b2d6ba97d520d954e46eaa
+  GNU                  0x00000014      NT_GNU_BUILD_ID (unique build ID
bitstring)         Build ID: 156d9c0ba3cc3b183e52e29aa814bda4bfec1f84

 Displaying notes found in: .gnu.build.attributes
   Owner                Data size       Description
   GA$<version>3a1              0x00000010      OPEN        Applies to region
from 0x9df000 to 0x661aeb2
-  GA$<version>3p1093           0x00000010      OPEN        Applies to region
from 0xcb7372 to 0xcb7d6e
+  GA$<version>3p1092           0x00000010      OPEN        Applies to region
from 0xcb7372 to 0xcb7d6e
   GA*<stack prot>strong        0x00000000      OPEN        Applies to region
from 0xcb7372 to 0xcb7d6e
-  GA$<tool>annobin gcc 12.2.1 20220819 0x00000000      OPEN        Applies to
region from 0xcb7372 to 0xcb7d6e
-  GA$<tool>plugin name: annobin 0x00000000     OPEN        Applies to region
from 0xcb7372 to 0xcb7d6e
+  GA$<tool>annobin gcc 12.2.1 20221121 0x00000000      OPEN        Applies to
region from 0xcb7372 to 0xcb7d6e
+  GA$<tool>plugin name: gcc-annobin 0x00000000 OPEN        Applies to region
from 0xcb7372 to 0xcb7d6e
   GA$<tool>running gcc 12.2.1 20221121 0x00000000      OPEN        Applies to
region from 0xcb7372 to 0xcb7d6e
   GA*<ABI>0x12                 0x00000000      OPEN        Applies to region
from 0xcb7372 to 0xcb7d6e
   GA*<PIC>PIC                  0x00000000      OPEN        Applies to region
from 0xcb7372 to 0xcb7d6e

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