lkml.org 
[lkml]   [2011]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH] perf report: add sort by file lines
    From
    Date
    On Wed, 2011-03-30 at 09:04 +0800, Masami Hiramatsu wrote:
    > (2011/03/30 2:45), Arnaldo Carvalho de Melo wrote:
    > > Em Tue, Mar 29, 2011 at 07:08:53PM +0200, Peter Zijlstra escreveu:
    > >> On Tue, 2011-03-29 at 19:06 +0200, Peter Zijlstra wrote:
    > >>> On Tue, 2011-03-29 at 19:03 +0200, Peter Zijlstra wrote:
    > >>>>> Is it an unwind of the call frame stack to find out what data member was
    > >>>>> accessed?
    > >
    > >>>> No need to unwind stacks, DWARF should have information on function
    > >>>> local stack. It should be able to tell you the type of things like -8(%
    > >>>> rbp).
    > >
    > >>> That is, we don't even have a life stack to unwind, so we simply cannot
    > >>> unwind at all, but the debug information should be able to tell you the
    > >>> type of whatever would live at a certain stack position if we were to
    > >>> have a stack.
    > >
    > >> Furthermore, I've now completely exhausted my knowledge of debuginfo and
    > >> hope Masami and Arnaldo will help with further details ;-)
    > >
    > > :-)
    > >
    > > I think the place to look is 'perf probe', look for the way one
    > > variable is translated to an expression passed to the kprobe_tracer, I
    > > think you'll need the reverse operation.
    > >
    > > Look at tools/perf/util/probe-finder.c, function find_variable() and
    > > convert_variable_location().
    >
    > Right, perf probe is available for looking up a variable at
    > an address, however, since it just depends on the dwarf,
    > we can just know the mapping from (actual) variables to
    > locations (registers/stacks etc.)
    >
    > It seems that Peter requires more than that, his request is
    > getting a map from (temporarily used) register to a specific
    > member of a data structure pointed by a pointer. But dwarf is
    > not enough for that.
    >
    > Peter gave us a good example of that.
    >
    > > void foo(struct foo *foo, struct tmp *tmp)
    > > {
    > > foo->bar->fubar = tmp->blah;
    > > }
    > >
    > > foo:
    > > .cfi_startproc
    > > pushq %rbp
    > > .cfi_def_cfa_offset 16
    > > movq %rsp, %rbp
    > > .cfi_offset 6, -16
    > > .cfi_def_cfa_register 6
    > > movq %rdi, -8(%rbp)
    > > movq %rsi, -16(%rbp)
    > > movq -8(%rbp), %rax /* load foo arg from stack */
    > > movq 24(%rax), %rax /* load foo->bar */
    > > movq -16(%rbp), %rdx /* load tmp arg from stack */
    > > movl 32(%rdx), %edx /* load tmp->blah */
    > > movl %edx, 20(%rax) /* store bar->fubar */ <<==(1)
    > > leave
    > > ret
    > > .cfi_endproc
    >
    > At (1), dwarf tells us the location of 'foo' is -8(%rbp) and 'tmp' is
    > -16(%rbp), but doesn't know to what 20(%rax) is mapped, because
    > foo->bar->fubar is not a real variable.

    I am considering if it is possible to do "instruction unwind" to get a
    map from (temporarily used) register to a specific member of a data
    structure pointed by a pointer.

    4004a0: movq -8(%rbp), %rax /* load foo arg from stack */
    4004a4: movq 24(%rax), %rax /* load foo->bar */
    4004a8: movq -16(%rbp), %rdx /* load tmp arg from stack */
    4004ac: movl 32(%rdx), %edx /* load tmp->blah */
    4004af: movl %edx, 20(%rax) /* store bar->fubar */

    foo: -8(%rbp)
    tmp: -16(%rbp)

    Assume we are now at ip 4004af, from the instruction decoder, we know
    it's a store operation, and we want to find out what %rax is.

    1. unwind to 4004ac
    Ignore this, because it does not touch %rax

    2. unwind to 4004a8
    Ignore this, because it does not touch %rax

    3. unwind to 4004a4
    20(%rax) => 20(24(%rax)), continue to unwind because we still
    have no idea what %rax is

    4. unwind to 4004a0
    20(24(%rax)) => 20(24(-8(%rbp))), stop unwind, because we now know
    -8(%rbp) is foo.

    So the original 20(%rax) is replace as 20(24(-8(%rbp))), and it means
    foo->bar->fubar

    Does this make sense?

    Thanks,
    Lin Ming

    >
    > So that what we need is a kind of the reverse compiler which generates
    > intermediate code (a sequence of register assignments) from
    > instruction code. That's not impossible task, but just hard and fun. :)
    > For that purpose, we'll need an instruction decoder and an evaluator
    > which allows us to trace the sequence of address dereferences.
    >
    > Anyway, I'd recommend that we should start with just showing
    > the corresponding "source line" of the address. It may be
    > enough for some cases.
    >
    > Thank you,
    >
    >




    \
     
     \ /
      Last update: 2011-03-31 10:49    [W:0.039 / U:64.292 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site