| lists.openwall.net | 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 Mar 2011 19:03:03 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Lin Ming <ming.m.lin@...el.com>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Frederic Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] perf report: add sort by file lines
On Wed, 2011-03-30 at 00:45 +0800, Lin Ming wrote:
> On Tue, 2011-03-29 at 17:54 +0800, Peter Zijlstra wrote:
> > On Tue, 2011-03-29 at 17:32 +0800, Lin Ming wrote:
> > >
> > > Peter suggested to reverse map the reported IP (PEBS + fixup)
> > > to a data access using dwarf info.
> > > So I wrote this patch to see if the direction is right.
> >
> > I'm not sure this is quite the same thing, I'm not arguing this might
> > not be useful, but this is not about data access.
> >
> > Suppose you have a line like:
> >
> > foo->bar->fubar = tmp->blah;
> >
> > There's 3 indirections there, a line number doesn't even get you close
> > to knowing what data access triggered the event.
> >
> > struct bar {
> > int poekoe[5];
> > int fubar;
> > };
> >
> > struct foo {
> > long poekoe[3];
> > struct bar *bar;
> > };
> >
> > struct tmp {
> > long poekoe[4];
> > int blah;
> > };
> >
> > void foo(struct foo *foo, struct tmp *tmp)
> > {
> > foo->bar->fubar = tmp->blah;
> > }
> >
> > Which gives (somewhat simplified):
> >
> > 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 */
> > leave
> > ret
> > .cfi_endproc
>
> I need to have a close look at how dwarf cfi thing works.
You'll need more than CFI.
> >
> > where I annotated the various moves with C comments.
> >
> > Now depending on what exact IP you get using PEBS+fixup you could using
> > DWARF bits generate similar deductions from the code as I did in those
> > comments and thus know exactly what data member was accessed and how
> > (read/write).
>
> 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).
> How to know the access type(read or write)?
instruction decode, see if the memory operand is a source or target.
> >
> > With that data you could then borrow some pahole code and annotate the
> > various data structures to illustrate read/write distributions, which
> > can then be used as input for data-reorder.
>
> Could you explain a bit more about this?
$ pahole tmp.o
struct tmp {
long int poekoe[4]; /* 0 32 */
int blah; /* 32 4 */
/* size: 40, cachelines: 1 */
/* padding: 4 */
/* last cacheline: 40 bytes */
}; /* definitions: 1 */
struct foo {
long int poekoe[3]; /* 0 24 */
struct bar * bar; /* 24 8 */
/* size: 32, cachelines: 1 */
/* last cacheline: 32 bytes */
}; /* definitions: 1 */
struct bar {
int poekoe[5]; /* 0 20 */
int fubar; /* 20 4 */
/* size: 24, cachelines: 1 */
/* last cacheline: 24 bytes */
}; /* definitions: 1 */
You could provide similar structure printout from the report function,
and add read/write statistics.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists