From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759525AbcHYNLh (ORCPT ); Thu, 25 Aug 2016 09:11:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40210 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758033AbcHYNLg (ORCPT ); Thu, 25 Aug 2016 09:11:36 -0400 From: Yauheni Kaliuta To: Jiri Olsa Cc: Masami Hiramatsu , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Michael Petlan , Namhyung Kim , pbunyan@redhat.com Subject: Re: [BUG] perf tool: uprobe displays wrong argument value References: <20160825120250.GB8319@krava> Date: Thu, 25 Aug 2016 16:11:47 +0300 In-Reply-To: <20160825120250.GB8319@krava> (Jiri Olsa's message of "Thu, 25 Aug 2016 14:02:50 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 25 Aug 2016 13:11:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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