Re: Bug#661193: linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 3425 bytes --]

Here's a bug report on perf; I don't think there's anything I can add to
Sami's explanation.

Ben.

On Sat, 2012-02-25 at 00:11 +0200, Sami Liedes wrote:
> Package: linux-tools-3.2
> Version: 3.2.1-2
> Severity: normal
> 
> Hi!
> 
> perf report does not show source code lines (annotation) for some
> binaries with separate debug information if those build-id's have been
> cached in perf's build-id cache. This is true for at least those
> packages whose debug symbols are installed in
> /usr/lib/debug/path/binary and not in
> /usr/lib/debug/.build-id/.../$hash. For example, e2fslibs, e2fsprogs
> and I believe very many others packages are affected by this (the
> mentioned packages even after fixing their -dbg packages per #661071).
> 
> This manifests with the following symptoms. If you want to test this,
> I suggest either waiting for a fix for #661071 to be uploaded or to
> choose a different package from e2fsprogs and its corresponding -dbg
> package (but not one where the -dbg package has files in the .build-id
> directory):
> 
> ------------------------------------------------------------
> 1. Compile a package with separate debug info (so that you have the
> sources available actually) and install both the package and the -dbg
> package. Use a binary from the package in place of dumpe2fs in
> following steps.
> 
> 2. Run perf record -g dumpe2fs $some_fs_image
> 
> 3. Run perf annotate
> 
> NOTE: functions in e.g. libext2fs.so.2.4 or in dumpe2fs are not
> annotated with source code lines
> 
> 4. run perf buildid-list. Note that it lists binaries for those
> non-annotated functions. Either find the file in the
> ~/.debug/.build-id directory tree, or investigate using
> perf annotate -vv (grep for "Executing:") where the file file
> resides.
> 
> 5. Note that the file you found is a copy of the binary or the library
> in question, *not* a copy of the relevant file from /usr/lib/debug.
> The objdump command that perf reports executing does not annotate it
> with source code lines. If you try that same line but replace the
> filename with the path to the actual binary, objdump knows where to
> find the debug info and does annotate it.
> 
> 6. mv perf.data perf.data.tmp
> 
> 7. perf record -g ls
> 
> (this step is important because it empties the build-id cache and
> populates it with objects needed for the ls execution; turns out perf
> handles annotating fine once the relevant object is no longer in the
> build-id cache)
> 
> 8. perf annotate -i perf.data.tmp
> 
> NOTE: the functions that were unannotated in step 3 in that old
> perf.data are now correctly annotated with source code.
> ------------------------------------------------------------
> 
> I think the actual bug is that, for some reason, in step 2 perf record
> copies the non-debug version to the build-id cache instead of the
> debug version. I have not investigated why this happens.
> 
> I also tried to remove the wrong file from the build-id cache and
> re-add the correct one with perf buildid-cache -v
> --remove=1a22c5f5c7a51ede62d01eeba1de59c15e7c9325; perf buildid-cache
> --add=/path/to/file, but for some reason I couldn't get that --remove=
> command to actually remove anything from the cache.
> 
> 	Sami


-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]