Re: [PATCH 00/21] perf, c2c: Add new tool to analyze cacheline contention on NUMA systems

[Arnaldo Carvalho de Melo <acme@ghostprotocols.net>]

Em Tue, Feb 11, 2014 at 12:14:21PM +0100, Peter Zijlstra escreveu:
> On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> > Assuming you can decode and get the info about the base registers used,
> > you'd have to do this for each arch with load/store sampling capabilities.
> > this is painful compared to getting the portable info from dwarf directly.
 
> But its useful now, as compared to whenever GCC gets around to
> implementing more dwarves and that GCC getting used widely enough to
> actually rely on it.
 
> All you need for the decode is a disassembler, and every arch should
> already have multiple of those. Should be easy to reuse one, right?

Yeah, I never got around to actually try to implement this, but my
feeling was that all the bits and pieces were there already:

1) the precise IP for the instruction, that disassembled would tell
which registers were being operated on, or memory that we would "reverse
map" to a register

2) DWARF expression locations that allows us to go from registers to a
variable/parameter and thus to a type

3) PERF_SAMPLE_REGS_USER (from a quick look, why do we have "USER" in
it? Jiri?)

4) libunwind have register maps for various arches, so probably
something there could be reused here as well (Jiri?)

Get that and generate a series of (type,offset) tuples for the samples
and get pahole to highlight the members with different colours, just
like 'annotate' does with source code/asm.

That way we would reuse 'pahole' in much the same way as we reuse
'objdump'. Give some more time to revisit the libdwarves APIs and then
we could use it directly on perf or perhaps extract just what is needed
and merge into the kernel sources.

- Arnaldo