Improved backtraces with srcline in perf report

[Milian Wolff <milian.wolff@kdab.com>]

[-- Attachment #1: Type: text/plain, Size: 4945 bytes --]

Hey all,

I would like to work on improving the usability of the way backtraces are 
reported by perf. See also my mail on that topic from a few weeks ago 
("usability issues with inlining and backtraces").

Status quo:

~~~~~~~~~~~~~~~~
perf report  --no-children -s dso,sym,srcline -g address --stdio
# Samples: 8K of event 'cycles:ppp'
# Event count (approx.): 8164367769
#
# Overhead  Shared Object               Symbol                                                              
Source:Line                                  
# ........  ..........................  
..................................................................  
.............................................
#
     7.82%  lab_mandelbrot              [.] main                                                            
mandelbrot.h:41
            |          
            |--2.84%--main mandelbrot.h:41
            |          __libc_start_main +241
            |          _start +4194346
            |          
            |--2.58%--main mandelbrot.h:41
            |          
             --2.01%--main mandelbrot.h:41
                       __libc_start_main +241
                       _start +4194346

     7.79%  libgcc_s.so.1               [.] __muldc3                                                        
libgcc2.c:1945
            |          
            |--3.93%--__muldc3 libgcc2.c:1945
            |          main mandelbrot.h:39
            |          __libc_start_main +241
            |          _start +4194346
            |          
             --3.72%--__muldc3 libgcc2.c:1945
                       main mandelbrot.h:39
                       __libc_start_main +241
                       _start +4194346
~~~~~~~~~~~~~~~~

Note: I have no idea why unwinding failed for the second main entry of 2.58% 
cost, but that is not topic of this email.

I would like to fix the following issues in descending priority. Please advise 
me whether these ideas are acceptable and, more importantly, where to 
implement them in the existing perf code base.

a) merge entries with equal labels

Most lines of code will contain multiple instructions. When translating them 
to srcline (-g address), the addresses will get mapped to the same labels. In 
the above case e.g. this distinction simply adds visual noise with no value at 
all. Instead, I'd like the report to show me:

~~~~~~~~~~~~~~~~
     7.82%  lab_mandelbrot              [.] main                                                            
mandelbrot.h:41
            |          
            |--4.85%--main mandelbrot.h:41
            |          __libc_start_main +241
            |          _start +4194346
            |          
            |--2.58%--main mandelbrot.h:41

     7.79%  libgcc_s.so.1               [.] __muldc3                                                        
libgcc2.c:1945
            |          
            |--7.79%--__muldc3 libgcc2.c:1945
            |          main mandelbrot.h:39
            |          __libc_start_main +241
            |          _start +4194346
~~~~~~~~~~~~~~~~

The merging of the entries must take backtraces into account, but must not 
merge based on the the ip/address of entries in the backtrace, but merge based 
on the symbol/label.

Especially for more complex applications, where the same code gets called from 
different functions (and we thus have different backtraces), this aggregation 
of costs will greatly simplify the analysis.

b) Add inliners

The above report is highly confusing, as a lot of code gets inlined and perf 
does not show the symbols of inlined functions. I.e. I'd like the report to 
show me:

~~~~~~~~~~~~~~~~
     7.82%  lab_mandelbrot              [.] drawMandelbrot                                                            
mandelbrot.h:41
            |          
            |--4.85%--drawMandelbrot mandelbrot.h:41
            |          main main.cpp:55
            |          __libc_start_main +241
            |          _start +4194346
            |          
            |--2.58%--drawMandelbrot mandelbrot.h:41
            |          main main.cpp:55

     7.79%  libgcc_s.so.1               [.] __muldc3                                                        
libgcc2.c:1945
            |          
            |--7.79%--__muldc3 libgcc2.c:1945
            |          std::complex<double>::operator*=<double> complex:1326
            |          main mandelbrot.h:39
            |          __libc_start_main +241
            |          _start +4194346
~~~~~~~~~~~~~~~~

The information for that exists in DWARF and can already be read out in perf 
using the `bfd_find_inliner_info` code in util/srcline.c:addr2line. 

Could someone please tell me what refactoring is required to make this work in 
perf? It seems to be non-trivial.

-- 
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]