Re: [RFC][PATCH 1/2] perf: Add 'perf kmem' tool

From: Arnaldo Carvalho de Melo
Date: Fri Nov 20 2009 - 12:52:46 EST


Em Fri, Nov 20, 2009 at 05:41:10PM +0100, Ingo Molnar escreveu:
> > So we have a mechanism that is already present in several distros
> > (build-id), that is in the kernel build process since ~2.6.23, and that
> > avoids using mismatching DSOs when resolving symbols.
>
> But what do we do if we have another box that runs say on a MIPS CPU,
> uses some minimal distro - and copy that perf.data over to an x86 box.

There would be no problem, it would be just a matter of installing the
right -debuginfo packages, for MIPS.

Or the original, unstripped FS image sent to the machine with the MIPS
cpu, if there aren't -debuginfo packages.

Either one, the right DSOs would be found by the buildids.

There are other scenarios, like a binary that gets updated while a long
running perf record session runs, the way to differentiate between the
two DSOs wouldn't be the name, but the buildid.

> The idea is there to be some new mode of perf.data where all the
> relevant DSO contents (symtabs but also sections with instructions for
> perf annotate to work) are copied into perf.data, during or after data
> capture - on the box that does the recording.
>
> Once we have everything embedded in the perf.data, analysis passes only
> have to work based on that particular perf.data - no external data.

Well, we can that, additionally, but think about stripped binaries, we
would lose potentially a lot because the symtabs on that small machine
would have poorer symtabs than the ones in an unstriped binary (or in a
-debuginfo package).

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/