Re: [PATCH v2] perf trace: Fix missing handling of --call-graph dwarf

[Hendrik Brueckner <brueckner@linux.vnet.ibm.com>]

On Mon, Jan 15, 2018 at 10:57:52AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jan 15, 2018 at 01:31:00PM +0100, Thomas-Mich Richter escreveu:
> > On 01/12/2018 09:02 PM, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Jan 12, 2018 at 01:47:06PM -0300, Arnaldo Carvalho de Melo escreveu:
> > >
> [root@jouet ~]# perf trace --no-syscalls --call-graph fp --max-stack 3 -e probe_libc:inet_pton ping -6 -c 1 ::1
> perf trace --no-syscalls --call-graph dwarf --max-stack 3 -e probe_libc:inet_pton ping -6 -c 1 ::1
> PING ::1(::1) 56 data bytes
> 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.080 ms
> 
> --- ::1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.080/0.080/0.080/0.000 ms
>      0.000 probe_libc:inet_pton:(7f33e9647350))
>                                        __inet_pton (inlined)
>                                        gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
>                                        __GI_getaddrinfo (inlined)
> [root@jouet ~]# 
> 
> And here we see a difference in the fp and DWARF unwinders, have to dig
> deeper into this one, perhaps using the DWARF one we have more info and
> then can end up with inlines instead of what it calls.

DWARF includes information about which functions are inlined.  The ORC
unwinder data is based on the analysis of the generated instructions
(created with the objtool).  Hence, it does no (and no longer) know whether
a bunch of instructions are originally part of a function or inlined.

Thanks and kind regards,
  Hendrik