seen with the test debs in PR18791 $ abipkgdiff --d1 debs+ddebs/libsigc++-2.0-0c2a-dbgsym_2.4.1-1_amd64.ddeb --d2 debs+ddebs/libsigc++-2.0-0v5-dbgsym_2.4.1-2_amd64.ddeb debs+ddebs/libsigc++-2.0-0c2a_2.4.0-1_amd64.deb debs+ddebs/libsigc++-2.0-0v5_2.4.1-2_amd64.deb 2>&1|less ================ changes of 'libsigc-2.0.so.0.0.0'=============== Functions changes summary: 0 Removed, 0 Changed, 1 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 1 Removed, 0 Added function symbol not referenced by debug info Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info 1 Added function: 'method void std::__cxx11::_List_base<sigc::slot_base, std::allocator<sigc::slot_base> >::_M_clear()' {_ZNSt7__cxx1110_List_baseIN4sigc9slot_baseESaIS2_EE8_M_clearEv} 1 Removed function symbol not referenced by debug info: _ZNSt10_List_baseIN4sigc9slot_baseESaIS1_EE8_M_clearEv ================ end of changes of 'libsigc-2.0.so.0.0.0'=============== running abidiff in the temp directory: $ abidiff --d1 debug_package1 --d2 debug_package2 package1/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 package2/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 1 Removed, 1 Added function symbols not referenced by debug info Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info 1 Removed function symbol not referenced by debug info: _ZNSt10_List_baseIN4sigc9slot_baseESaIS1_EE8_M_clearEv 1 Added function symbol not referenced by debug info: _ZNSt7__cxx1110_List_baseIN4sigc9slot_baseESaIS2_EE8_M_clearEv calling $ abidiff --d1 debug_package1/usr/lib/debug --d2 debug_package2/usr/lib/debug package1/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 package2/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 show the same result. $ find ! -type d ./debug_package1/usr/lib/debug/.build-id/2a/9196834bc02c2ba4b6f1bae7646cbec0c19f50.debug ./package1/usr/share/lintian/overrides/libsigc++-2.0-0c2a ./package1/usr/share/doc/libsigc++-2.0-0c2a/changelog.Debian.gz ./package1/usr/share/doc/libsigc++-2.0-0c2a/copyright ./package1/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0.0.0 ./package1/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 ./debug_package2/usr/lib/debug/.build-id/b3/79585e5ca5f2eac0650dac2b6008756018f7d5.debug ./package2/usr/share/lintian/overrides/libsigc++-2.0-0v5 ./package2/usr/share/doc/libsigc++-2.0-0v5/changelog.Debian.gz ./package2/usr/share/doc/libsigc++-2.0-0v5/copyright ./package2/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0.0.0 ./package2/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
Created attachment 8499 [details] debs2.tar the detached debug information in the first tarball was built with --build id. The deb2.tar now contains the packages built with the old debug_link method. But it is still not finding the debug information.
For the record, this bug report is for abipkgdiff augmented by the patch that you submitted at https://sourceware.org/bugzilla/show_bug.cgi?id=18782. I am adding that tracking bug as a dependency to this one, otherwise, one might wrongly think that this bug is found in current master.
Created attachment 8516 [details] updated test data test data for the build-id case. The former ones were not matching. It would be nice to give a warning or error when the build id's for the package and the debug package don't match.
(In reply to Matthias Klose from comment #1) > Created attachment 8499 [details] > debs2.tar > > the detached debug information in the first tarball was built with --build > id. The deb2.tar now contains the packages built with the old debug_link > method. But it is still not finding the debug information. I have looked into the issue here, and it's true that libabigail cannot find the split debug info when the setup doesn't use the build-id mechanism. Here is an easier-to-debug reproducer: $ mkdir -p extract/package1 $ mkdir -p extract/package2 $ dpkg -x libsigc++-2.0-0c2a-dbgsym_2.4.0-1_amd64.ddeb extract/debug_package1/ $ dpkg -x libsigc++-2.0-0c2a_2.4.0-1_amd64.deb extract/package1/ $ ~/git/libabigail.git/patch-review/build/tools/abidw --debug-info-dir extract/debug_package1/usr/lib/debug extract/package1/usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 | grep "<abi-instr" | wc -l 0 The output of abidiw should have several xml element named "abi-instr", *IF*, abidw could find the debug information. In this case of binary not using the build-id scheme to locate its associated debug info, what we see above is that abidw (and hence libabigail) is not finding the debug info.
Created attachment 8517 [details] A patch to elfutils that fixes locating the debug info file when build-id is not used This patch is to be applied to elfutils, master. Here is its cover letter. suppose we have a debug info file that is located at a /prefix1/usr/lib/debug/prefix2/libfoo.so. Suppose also that the debug info describes a binary that is located at /prefix1/prefix2/libfoo.so Suppose the debug_link property inside the binary /prefix1/prefix2/libfoo.so correctly contains the string "libfoo.so" that designates the name of the debug info file. The problem is, when find_debuginfo_in_path() is called with its file_name parameter set to "/prefix1/prefix2/libfoo.so" and mod->dwfl->callbacks->debuginfo_path set to "/prefix1/lib/debug/prefix2/libfoo.so", it fails to locate the debug info file libfoo.so under "/prefix1/lib/debug". This patch fixes the issue by making find_debuginfo_in_path() try all the sub-strings of "/prefix1/prefix2/libfoo.so "under" "/prefix1/usr/lib/debug/", to find libfoo.so. That is, it tries, in order: - /prefix1/usr/lib/debug/prefix1/prefix2/libfoo.so - /prefix1/usr/lib/debug/prefix2/libfoo.so <-- and boom, it finds it! Note that the patch tries the variations between the two candidates above too. The patch uses a goto. I dislike gotos like anyone else, but then here, not using this would imply a bigger change of the logic of that function. So I am proposing the scheme based on the goto instead. The patch lacks a test case, but then it's a bit cumbersome to write one right now. I'll defer that to later when people agree with the general approach of the patch.
I have just filed a bug to elfutils at https://bugzilla.redhat.com/show_bug.cgi?id=1253367 for this.
The elfutils fix was committed to its master branch, so I am closing this bug now. Thank you for reporting it.