Description of problem: ------------------------------------------------------------ Binaries that are compiled with LTO have source file name mismatches when SystemTap is used to print the probe points. Specifically, we compiled BusyBox-1.30.1 with and without LTO, and observed that some probe points have file name mismatches. Version-Release number of selected component (if applicable): ------------------------------------------------------------ gcc version 9.2.1 How reproducible: ------------------------------------------------------------ Always Steps to reproduce: ------------------------------------------------------------ 1. Get the BusyBox sources from https://busybox.net/downloads/busybox-1.30.1.tar.bz2 and extract them. 2. Make the BusyBox configuration by running $make allnoconfig && make menuconfig. 3. In the menu, navigate to Coreutils and select "echo". 3. Additionally, navigate to Settings > Additional CFLAGS, and set it as '-g -flto -ffat-lto-objects'. 3. Save and exit the configuration menu, and run $make to generate the binaries. 4. Run $stap -e 'probe process.function("echo_main") { println(pp()) }' -c './busybox_unstripped echo foo'. Actual results: ------------------------------------------------------------ foo process("/home/user/Downloads/busybox-1.30.1/busybox_unstripped").function("echo_main@libbb/appletlib.c:83") Expected results: ------------------------------------------------------------ foo process("/home/user/Downloads/busybox-1.30.1/busybox_unstripped").function("echo_main@coreutils/echo.c:83") Additional info: ------------------------------------------------------------ Source file for libbb/appletlib.c: https://git.busybox.net/busybox/tree/libbb/appletlib.c?h=1_30_stable#n83. We can see that the file name has a mismatch. We can get the expected results if we remove the -flto -ffat-lto-objects flags. We can also open this against upstream gcc if needed. Entire $gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
There is an easier way to reproduce this bug. Make the two binaries (with and without LTO) and run: $addr2line -e busybox_unstripped `nm busybox_unstripped | grep echo_main | awk '{print "0x"$1}' `. Actual Result: addr2line: DWARF error: could not find abbrev number 66 Expected Result: /home/user/Downloads/busybox-1.30.1/coreutils/echo.c:84
To me that looks like addr2line bug, and eu-addr2line instead of addr2line works just fine. readelf -wi shows: Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length: 0xd9ad (32-bit) Version: 4 Abbrev Offset: 0x0 Pointer Size: 8 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit) ... <1><115>: Abbrev Number: 8 (DW_TAG_subprogram) <116> DW_AT_abstract_origin: <0x1e2a7> <11a> DW_AT_low_pc : 0x402742 <122> DW_AT_high_pc : 0xb <12a> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <12c> DW_AT_GNU_all_call_sites: 1 ... Compilation Unit @ offset 0x1a5eb: Length: 0x6f01 (32-bit) Version: 4 Abbrev Offset: 0x216d Pointer Size: 8 <0><1a5f6>: Abbrev Number: 1 (DW_TAG_compile_unit) ... <1><1e2a7>: Abbrev Number: 66 (DW_TAG_subprogram) <1e2a8> DW_AT_name : (indirect string, offset: 0x2341): pungetc <1e2ac> DW_AT_decl_file : 39 <1e2ad> DW_AT_decl_line : 10704 <1e2af> DW_AT_decl_column : 1 <1e2b0> DW_AT_prototyped : 1 The error that is emitted is while reading the DW_AT_abstract_origin attribute at offset 0x116 into .debug_info. 3178 case DW_AT_abstract_origin: 3179 case DW_AT_specification: 3180 if (!find_abstract_instance (unit, info_ptr, &attr, 3181 &func->name, 3182 &func->is_linkage, 3183 &func->file, 3184 &func->line)) 3185 goto fail; 3186 break; attr is DW_AT_abstract_origin with DW_FORM_ref_addr. Trying latest git binutils, addr2line works fine on it too, I bet https://sourceware.org/bugzilla/show_bug.cgi?id=25230 fixed it.
OK, I have imported the patches for PR 25230 (and several others in this area) and incorporated them into binutils-2.31.1-37.fc30. Updates for F31 and rawhide are in the works and I will update this BZ when they are ready.
The fixes are now in F31 (binutils-2.32-31.fc31) and rawhide (binutils-2.33.1-11.fc32).
FEDORA-2020-d3a71a166f has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d3a71a166f
FEDORA-2020-7dc56628ff has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7dc56628ff
binutils-2.31.1-37.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d3a71a166f
binutils-2.32-31.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7dc56628ff
binutils-2.32-31.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
binutils-2.31.1-37.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.