lkml.org 
[lkml]   [2012]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Bug#661193: linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions
From
Date
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.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2012-02-26 05:41    [W:4.058 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site