Bug 18792 - reading the detached debug information doesn't work
Summary: reading the detached debug information doesn't work
Status: RESOLVED FIXED
Alias: None
Product: libabigail
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Dodji Seketeli
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-09 08:45 UTC by Matthias Klose
Modified: 2015-08-22 21:45 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
debs2.tar (95.04 KB, application/x-tar)
2015-08-10 19:50 UTC, Matthias Klose
Details
updated test data (94.68 KB, application/x-tar)
2015-08-13 13:44 UTC, Matthias Klose
Details
A patch to elfutils that fixes locating the debug info file when build-id is not used (1.34 KB, patch)
2015-08-13 14:29 UTC, Dodji Seketeli
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2015-08-09 08:45:18 UTC
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
Comment 1 Matthias Klose 2015-08-10 19:50:44 UTC
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.
Comment 2 Dodji Seketeli 2015-08-13 09:23:03 UTC
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.
Comment 3 Matthias Klose 2015-08-13 13:44:38 UTC
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.
Comment 4 Dodji Seketeli 2015-08-13 13:56:33 UTC
(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.
Comment 5 Dodji Seketeli 2015-08-13 14:29:04 UTC
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.
Comment 6 Dodji Seketeli 2015-08-13 14:45:09 UTC
I have just filed a bug to elfutils at https://bugzilla.redhat.com/show_bug.cgi?id=1253367 for this.
Comment 7 Dodji Seketeli 2015-08-22 21:45:26 UTC
The elfutils fix was committed to its master branch, so I am closing this bug now. Thank you for reporting it.