lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Sun, 26 Feb 2012 04:37:35 +0000
From:	Ben Hutchings <>
To:	Peter Zijlstra <>,
	Paul Mackerras <>, Ingo Molnar <>,
	Arnaldo Carvalho de Melo <>
Cc:, Sami Liedes <>,
	LKML <>
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.


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. 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
> 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
> NOTE: the functions that were unannotated in step 3 in that old
> 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