Message-ID: <1330231055.8460.26.camel@deadeye>
Date:	Sun, 26 Feb 2012 04:37:35 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc:	661193@...s.debian.org, Sami Liedes <sami.liedes@....fi>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Bug#661193: linux-tools-3.2: perf fails to annotate code with
 separate debug info under some conditions

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.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists