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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 25 Aug 2016 16:11:47 +0300
From:   Yauheni Kaliuta <yauheni.kaliuta@...hat.com>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Michael Petlan <mpetlan@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>, pbunyan@...hat.com
Subject: Re: [BUG] perf tool: uprobe displays wrong argument value

Hi, Jiri!

>>>>> On Thu, 25 Aug 2016 14:02:50 +0200, Jiri Olsa  wrote:

[...]

 > Now here's where I got confused..  please continue reading only on your own risk ;-)

 > The uprobe_events shows following record:
 >         # cat uprobe_events 
 >         p:probe_ex/func /home/jolsa/linux-perf/tools/perf/ex:0x00000000000004f6 par=-12(%sp):s32

 > I can't see how ($rsp - 12) address could hold the 'par' value,
 > when we stop at the 'func' addreess, so where did it come from?

 > I figured it's the debug info, namely the par argument's CU:

 >         $ readelf --debug-dump ./ex | less
 >         ...

 >          <2><94>: Abbrev Number: 5 (DW_TAG_formal_parameter)
 >             <95>   DW_AT_name        : par
 >             <99>   DW_AT_decl_file   : 1
 >             <9a>   DW_AT_decl_line   : 3
 >             <9b>   DW_AT_type        : <0x57>
 >             <9f>   DW_AT_location    : 2 byte block: 91 6c      (DW_OP_fbreg: -20)

 > which says the value is frame buffer reg -20.. I can't see
 > this will get the proper value for any of $rbp or $rsp even
 > after new func's stack frame is set..

I see how it can do that:

Breakpoint 1, main () at 1.c:10
10        int a = 1;
(gdb) p &a
$1 = (int *) 0x7fffffffe9cc
(gdb) br *0x00000000004004d6
Breakpoint 2 at 0x4004d6: file 1.c, line 4.

(before the prologue, as you did)

Breakpoint 2, func (par=0) at 1.c:4
4       {
(gdb) p $rsp + 20
$2 = (void *) 0x7fffffffe9cc (same as &a).


So DW_OP_call_frame_cfa restores %rsp before the function call.



 > Also if I set gdb to stop directly on the function address,
 > it shows wrong value:

 >         # gdb ./ex
 >         (gdb) b *0x4004f6
 >         Breakpoint 1 at 0x4004f6: file ex.c, line 4.
 >         (gdb) r
 >         Starting program: /home/jolsa/linux-perf/tools/perf/ex 
 >         Missing separate debuginfos, use: dnf debuginfo-install glibc-2.21-13.fc22.x86_64

 >         Breakpoint 1, func (par=0) at ex.c:4
 >         4       {
 >         (gdb) 

 > Apart from when I set the breakpoint after the new stack frame is set:

 >         (gdb) b func
 >         Breakpoint 1 at 0x4004fd: file ex.c, line 5.
 >         (gdb) r
 >         Starting program: /home/jolsa/linux-perf/tools/perf/ex 
 >         Missing separate debuginfos, use: dnf debuginfo-install glibc-2.21-13.fc22.x86_64

 >         Breakpoint 1, func (par=1) at ex.c:5
 >         5               return par;


 > I'm clearly missing something..

 > thanks for help,
 > jirka


 > ---
 > kernel version: 4.8.0-rc2
 > perf version: latest Arnaldo's perf/core


-- 
WBR,
Yauheni Kaliuta

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ