[Bug binutils/29390] New: On aarch64 binaries readelf --debug-dump=frames reports DW_CFA_AARCH64_negate_ra_state as DW_CFA_GNU_window_save
https://sourceware.org/bugzilla/show_bug.cgi?id=29390
Bug ID: 29390
Summary: On aarch64 binaries readelf --debug-dump=frames
reports DW_CFA_AARCH64_negate_ra_state as
DW_CFA_GNU_window_save
Product: binutils
Version: 2.37
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: wcohen at redhat dot com
Target Milestone: ---
When reviewing the output of readelf --debug-dump=frames I noticed that the
output for aarch64 contained DW_CFA_GNU_window_save rather than the expected
DW_CFA_AARCH64_negate_ra_state. Both of the call frame instructions are coded
as 0x2d. However, the DW_CFA_GNU_window_save is for sparc binaries and the
DW_CFA_AARCH64_negate_ra_state is for aarch64 binaries.
It is pretty easy to demonstrate the issue on a fedora 36 aarch64 system with
the steps below. They shows many DW_CFA_GNU_window_save entries rather than
DW_CFA_AARCH64_negate_ra.
sudo dnf install systemtap
readelf --debug-dump=frames /usr/bin/stap |grep -v "^0" | awk -F: '{print
$1}'|grep DW_CFA |sort | uniq -c
26096 DW_CFA_advance_loc
783 DW_CFA_advance_loc1
193 DW_CFA_advance_loc2
5 DW_CFA_def_cfa
5908 DW_CFA_def_cfa_offset
2 DW_CFA_def_cfa_register
5901 DW_CFA_GNU_window_save
5014 DW_CFA_nop
27676 DW_CFA_offset
35 DW_CFA_offset_extended
3110 DW_CFA_remember_state
26685 DW_CFA_restore
32 DW_CFA_restore_extended
3110 DW_CFA_restore_state
1 DW_CFA_undefined
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 William Cohen changed: What|Removed |Added CC||wcohen at redhat dot com --- Comment #1 from William Cohen --- Looked at the number of notes in the libxul.so found that there were about 4 million lines of output with the following: fche, hmm. there looks to be a huge amount of notes in libxul.so. $ cd ~/rpmbuild/BUILD/firefox-108.0.1; readelf --notes --wide ./objdir/dist/firefox/libxul.so | wc readelf: ./objdir/dist/firefox/libxul.so: Warning: Gap in build notes detected from 0xb9f69a to 0x661ae9f 4378890 42206207 436839245 over 4 million lines of notes output for libxul.so. that might explain why so much time spent in objcopy. Used "perf report" to see where the samles were in merge_gnu_build_notes. The behavior is caused by the large number of notes and "Rule 2" linearly searching through the list of previous notes. Even if "identically attributed notes" are grouped together there can still be a lot to go through. There appears to be a lot merged out as the installed firefox libxul.so is much more compact: $ readelf --notes --wide /usr/lib64/firefox/libxul.so |wc readelf: /usr/lib64/firefox/libxul.so: Warning: Gap in build notes detected from 0xcb7d6f to 0x661aebf 86 8367897 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #2 from William Cohen --- I believe the large number of notes is because of the use of static libraries in the packages. Took a look at how the some of the shared libraries were generated in the mesa package which has a similar but not so extreme percentage of time taken by the gnu_merge_build_notes function (20% rather than 70% of the rpmbuild install). For example the libdpau_gallium.so.1.0.0 was linked with the following: [2390/2405] g++ -o src/gallium/targets/vdpau/libvdpau_gallium.so.1.0.0 src/gallium/targets/vdpau/libvdpau_gallium.so.1.0.0.p/target.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libvdpau_gallium.so.1.0.0 -Wl,--whole-archive src/gallium/frontends/vdpau/libvdpau_st.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/wcohen/rpmbuild/BUILD/mesa-22.1.7/.package_note-mesa-22.1.7-1.fc36.x86_64.ld -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection src/gallium/auxiliary/libgalliumvlwinsys.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/gallium/auxiliary/libgalliumvl.a src/gallium/auxiliary/libgallium.a src/compiler/nir/libnir.a src/compiler/libcompiler.a src/gallium/auxiliary/pipe-loader/libpipe_loader_static.a src/loader/libloader.a src/util/libxmlconfig.a src/gallium/winsys/sw/null/libws_null.a src/gallium/winsys/sw/wrapper/libwsw.a src/gallium/winsys/sw/dri/libswdri.a src/gallium/winsys/sw/kms-dri/libswkmsdri.a src/gallium/drivers/r300/libr300.a src/gallium/winsys/radeon/drm/libradeonwinsys.a src/gallium/drivers/r600/libr600.a src/mesa/libmesa.a src/compiler/glsl/libglsl.a src/compiler/glsl/glcpp/libglcpp.a src/mesa/libmesa_sse41.a src/gallium/drivers/radeonsi/libradeonsi_gfx6.a src/gallium/drivers/radeonsi/libradeonsi_gfx7.a src/gallium/drivers/radeonsi/libradeonsi_gfx8.a src/gallium/drivers/radeonsi/libradeonsi_gfx9.a src/gallium/drivers/radeonsi/libradeonsi_gfx10.a src/gallium/drivers/radeonsi/libradeonsi_gfx103.a src/gallium/drivers/radeonsi/libradeonsi.a src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a src/amd/addrlib/libaddrlib.a src/amd/common/libamd_common.a src/amd/llvm/libamd_common_llvm.a src/gallium/winsys/nouveau/drm/libnouveauwinsys.a src/gallium/drivers/nouveau/libnouveau.a -Wl,--version-script /home/wcohen/rpmbuild/BUILD/mesa-22.1.7/src/gallium/targets/vdpau/vdpau.sym -Wl,--dynamic-list /home/wcohen/rpmbuild/BUILD/mesa-22.1.7/src/gallium/targets/vdpau/../dri-vdpau.dyn -Wl,--gc-sections /usr/lib64/libz.so -pthread -lm /usr/lib64/libdrm.so /usr/lib64/libxcb-sync.so /usr/lib64/libxcb-present.so /usr/lib64/libxshmfence.so /usr/lib64/libxcb-xfixes.so /usr/lib64/libxcb-dri3.so /usr/lib64/libzstd.so /usr/lib64/libunwind.so -lLLVM-14 -lsensors /usr/lib64/libexpat.so /usr/lib64/libdrm_radeon.so -lLLVM-14 /usr/lib64/libelf.so -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 /usr/lib64/libdrm_amdgpu.so -lLLVM-14 /usr/lib64/libdrm_nouveau.so /usr/lib64/libxcb.so /usr/lib64/libX11-xcb.so /usr/lib64/libX11.so /usr/lib64/libxcb-dri2.so -Wl,--end-group Individual static library in there hvae thousands of lines of notes: $ readelf --notes --wide src/gallium/frontends/vdpau/libvdpau_st.a |wc 3192 29512 253834 $ readelf --notes --wide src/gallium/drivers/nouveau/libnouveau.a |wc 65270 604954 5272013 To see how much a difference there is between static and shared libraries notes I compared the static and shared libraries from libpfm-4.11.0-10.fc37.src.rpm. The static library has a couple orders of magnitude more notes than the shared library: [wcohen@haro SPECS]$ readelf --notes --wide /usr/lib64/libpfm.a |wc 9209 84135 705543 [wcohen@haro SPECS]$ readelf --notes --wide /usr/lib64/libpfm.so.4.10.1 |wc 32 2492467 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #4 from William Cohen --- Hi Nick, My (limited) understanding of the code is that first note in the like notes is kept and the later notes are merged into that first note. The downside of this is that there can be a lot of scanning backwards over the previously deleted notes to find that earlier kept note. Is there a choice which note to merge into which? Would it be possible to merge the previous note into the current note and delete the previous note? That would eliminate the repeated long backward scans to find the note to merge into that are currently dominating the firefox build install. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #7 from William Cohen --- 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_xul2023-01-16 11:41:07.068311517 -0500 @@ -1,15 +1,15 @@ Displaying notes found in: .note.gnu.build-id OwnerData size Description - GNU 0x0014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: c71b2c4767cf93aa91b2d6ba97d520d954e46eaa + GNU 0x0014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 156d9c0ba3cc3b183e52e29aa814bda4bfec1f84 Displaying notes found in: .gnu.build.attributes OwnerData size Description GA$3a1 0x0010 OPENApplies to region from 0x9df000 to 0x661aeb2 - GA$3p1093 0x0010 OPENApplies to region from 0xcb7372 to 0xcb7d6e + GA$3p1092 0x0010 OPENApplies to region from 0xcb7372 to 0xcb7d6e GA*strong0x OPENApplies to region from 0xcb7372 to 0xcb7d6e - GA$annobin gcc 12.2.1 20220819 0x OPENApplies to region from 0xcb7372 to 0xcb7d6e - GA$plugin name: annobin 0x OPENApplies to region from 0xcb7372 to 0xcb7d6e + GA$annobin gcc 12.2.1 20221121 0x OPENApplies to region from 0xcb7372 to 0xcb7d6e + GA$plugin name: gcc-annobin 0x OPENApplies to region from 0xcb7372 to 0xcb7d6e GA$running gcc 12.2.1 20221121 0x OPENApplies to region from 0xcb7372 to 0xcb7d6e GA*0x12 0x OPENApplies to region from 0xcb7372 to 0xcb7d6e GA*PIC 0x OPENApplies to region from 0xcb7372 to 0xcb7d6e -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25057] New: Fails to build binutils-2.31.1 using clang-8.0.0
https://sourceware.org/bugzilla/show_bug.cgi?id=25057 Bug ID: 25057 Summary: Fails to build binutils-2.31.1 using clang-8.0.0 Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: wcohen at redhat dot com Target Milestone: --- When attempting to build binutils-2.31.1 rpm on fedora 30 using the clang compiler some of the code fails to build. Steps to reproduce: $ rpm -Uvh binutils-2.31.1.fc30.src.rpm $ cd rpmbuild/SPECS $ export CC=clang $ export CXX=clang++ $ rpmbuild --define "%optflags -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fcf-protection" --define "%dist .fc30llvm" -bi binutils.spec It compiles a fair amount of code, but the build fails because of the following errors: x86_64.cc:1591:10: error: case value evaluates to 3221225473, which cannot be narrowed to type 'int' [-Wc++11-narrowing] case elfcpp::GNU_PROPERTY_X86_ISA_1_NEEDED: ^ x86_64.cc:1592:10: error: case value evaluates to 3221225474, which cannot be narrowed to type 'int' [-Wc++11-narrowing] case elfcpp::GNU_PROPERTY_X86_FEATURE_1_AND: ^ The definitions of these values set sign bit (0xc001 and 0xc002) and it looks like clang doesn't like that. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/28441] New: [RISCV] ld linker relaxation is really slow
https://sourceware.org/bugzilla/show_bug.cgi?id=28441 Bug ID: 28441 Summary: [RISCV] ld linker relaxation is really slow Product: binutils Version: 2.35 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: wcohen at redhat dot com Target Milestone: --- Created attachment 13718 --> https://sourceware.org/bugzilla/attachment.cgi?id=13718&action=edit perf annotation of riscv_relax_delete_bytes function After getting perf annotate working for the RISCV (https://www.spinics.net/lists/linux-perf-users/msg14852.html) I collected perf data on systemtap being built on a prototype beagle v board to see where it was spending time. I noticed that the build was spending a very large amount of time (>90%) in the code of binutils implementing the relaxation (https://www.sifive.com/blog/all-aboard-part-3-linker-relaxation-in-riscv-toolchain). This binutils appears to be a Fedora 33 build of the stock binutils-2.35-18.fc33.riscv64 (http://fedora.riscv.rocks/koji/buildinfo?buildID=192459 ). Below is beginning of the "perf report --stdio" output: # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 5M of event 'task-clock:u' # Event count (approx.): 133005300 # # Overhead Command Shared Object Symbol # ... . # 94.46% ld libbfd-2.35-18.fc33.so [.] riscv_relax_delete_bytes 1.27% ld libc-2.32.so [.] _wordcopy_fwd_dest_aligned 0.81% ld libbfd-2.35-18.fc33.so [.] _bfd_riscv_relax_section.lto_priv.0 0.18% ld libbfd-2.35-18.fc33.so [.] elf_sort_elf_symbol 0.17% ld libbfd-2.35-18.fc33.so [.] bfd_elf_final_link 0.16% ld ld.bfd [.] sha1_process_block For more detail on riscv_relax_delete_bytes ran and added as an attachment: perf annotate riscv_relax_delete_bytes --stdio > ~/riscv_relax_delete_bytes.log -- You are receiving this mail because: You are on the CC list for the bug.
