perf userspace tools fixes for Ubuntu / linaro

Dave Martin dave.martin at
Tue Aug 3 12:13:24 UTC 2010

Hi there,

On Mon, Aug 2, 2010 at 10:10 PM, Chase Douglas
<chase.douglas at> wrote:
> On Mon, 2010-08-02 at 10:55 +0100, Dave Martin wrote:


> Thanks for passing this along! I am interested in figuring out whether
> we should backport the patches to Ubuntu Maverick.

Certainly would be nice to have, if there are developers who'd like to
use the tools.
The perf tools look like a good asset to have, but unpatched, they are
not very usable on Ubuntu yet (see below).

The patches only affect the userspace perf tools, so there's no risk
of destabilising the kernel etc. by applying the patches.

> I took a look at the first two patches that deal with the cwd issue.
> Although it fixes a real bug, I'm not sure it's worthwhile to pull it
> into the Ubuntu Maverick kernel because it's rather esoteric. For those


> Since the bug is likely never to be seen except when running perf inside
> system directories (which doesn't seem like a good usage scenario), I'm
> inclined to recommend not backporting this for Ubuntu.

Indeed--- I hit this a lot when trying to debug the perf tools ;) but
for most people it will be much more uncommon.  When profiling an app
from inside its own build tree, the debug will usually not have been
separated out already so it should work fine.

So it seems reasonable to allow this change to propagate in its own
time via mainline.

> However, I still don't fully understand the issue surrounding the
> buildid cache bug fix. Can you provide more details on the issue this is
> fixing? It may be something we want to consider for Maverick, but I need
> more info to know what's going on.

perf cleverly caches binaries during perf record, to ensure that later
analysis definitely uses the right symbols etc., even if binaries were
rebuilt / upgraded / removed in the meantime.

Unfortunately, it doesn't cleverly cache separate debug images yet
(i.e., ddebs contents).  So when searching for symbols during perf
report and friends, it hits in the cache and uses the stripped images
which were observed by perf record.  The result is that perf report
will only see symbols from .dynsym even if the ddebs are available ---
usually inadequate/misleading for profiling purposes.

The patch provides a workaround which looks in locations like
/usr/lib/debug anyway, if no matching image is found in the cache with
a non-empty .symtab.  This should make the tools signifcantly more
usable on Ubuntu.  Without the patch, the workaround is to pass
--no-buildid-cache to perf record, and to make sure there's no stale
cache content when running the other tools (to keep deleting ~/.debug
is the easiest way to ensure this -- perf buildid-cache is currently

Unfortunately, I hit another bug which causes code symbol locations to
get skewed in non-PIE executable images --- see follow-ups (starting
[PATCH 0/2] perf: symbol offset breakage with separated debug, to lkml
and kernel-team at ubuntu).  I believe there is no workaround for this
other than applying the patch... or building everything as PIE ;P


More information about the kernel-team mailing list