linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] perf report: fix off-by-one for non-activation frames
@ 2017-05-15 15:04 Milian Wolff
  2017-05-15 15:13 ` Milian Wolff
  2017-06-16  6:14 ` Jan Kratochvil
  0 siblings, 2 replies; 13+ messages in thread
From: Milian Wolff @ 2017-05-15 15:04 UTC (permalink / raw)
  To: Linux-kernel
  Cc: linux-perf-users, Milian Wolff, Arnaldo Carvalho de Melo,
	David Ahern, Namhyung Kim, Peter Zijlstra, Yao Jin

As the documentation for dwfl_frame_pc says, frames that
are no activation frames need to have their program counter
decremented by one to properly find the function of the caller.

This fixes many cases where perf report currently attributes
the cost to the next line. I.e. I have code like this:

~~~~~~~~~~~~~~~
  #include <thread>
  #include <chrono>

  using namespace std;

  int main()
  {
    this_thread::sleep_for(chrono::milliseconds(1000));
    this_thread::sleep_for(chrono::milliseconds(100));
    this_thread::sleep_for(chrono::milliseconds(10));

    return 0;
  }
~~~~~~~~~~~~~~~

Now compile and record it:

~~~~~~~~~~~~~~~
g++ -std=c++11 -g -O2 test.cpp
echo 1 | sudo tee /proc/sys/kernel/sched_schedstats
perf record \
    --event sched:sched_stat_sleep \
    --event sched:sched_process_exit \
    --event sched:sched_switch --call-graph=dwarf \
    --output perf.data.raw \
    ./a.out
echo 0 | sudo tee /proc/sys/kernel/sched_schedstats
perf inject --sched-stat --input perf.data.raw --output perf.data
~~~~~~~~~~~~~~~

Before this patch, the report clearly shows the off-by-one issue.
Most notably, the last sleep invocation is incorrectly attributed
to the "return 0;" line:

~~~~~~~~~~~~~~~
  Overhead  Source:Line
  ........  ...........

   100.00%  core.c:0
            |
            ---__schedule core.c:0
               schedule
               do_nanosleep hrtimer.c:0
               hrtimer_nanosleep
               sys_nanosleep
               entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
               __nanosleep_nocancel .:0
               std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323
               |
               |--90.08%--main test.cpp:9
               |          __libc_start_main
               |          _start
               |
               |--9.01%--main test.cpp:10
               |          __libc_start_main
               |          _start
               |
                --0.91%--main test.cpp:13
                          __libc_start_main
                          _start
~~~~~~~~~~~~~~~

When compiling perf using libdwfl for unwinding instead of libunwind
and having this patch here applied, the issue is fixed. The report
becomes much more usable:

~~~~~~~~~~~~~~~
  Overhead  Source:Line
  ........  ...........

   100.00%  core.c:0
            |
            ---__schedule core.c:0
               schedule
               do_nanosleep hrtimer.c:0
               hrtimer_nanosleep
               sys_nanosleep
               entry_SYSCALL_64_fastpath .tmp_entry_64.o:0
               __nanosleep_nocancel .:0
               std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323
               |
               |--90.08%--main test.cpp:8
               |          __libc_start_main
               |          _start
               |
               |--9.01%--main test.cpp:9
               |          __libc_start_main
               |          _start
               |
                --0.91%--main test.cpp:10
                          __libc_start_main
                          _start
~~~~~~~~~~~~~~~

Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Yao Jin <yao.jin@linux.intel.com>
Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
---
 tools/perf/util/unwind-libdw.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c
index f90e11a555b2..943a06291587 100644
--- a/tools/perf/util/unwind-libdw.c
+++ b/tools/perf/util/unwind-libdw.c
@@ -168,12 +168,16 @@ frame_callback(Dwfl_Frame *state, void *arg)
 {
 	struct unwind_info *ui = arg;
 	Dwarf_Addr pc;
+	bool isactivation;
 
-	if (!dwfl_frame_pc(state, &pc, NULL)) {
+	if (!dwfl_frame_pc(state, &pc, &isactivation)) {
 		pr_err("%s", dwfl_errmsg(-1));
 		return DWARF_CB_ABORT;
 	}
 
+	if (!isactivation)
+		--pc;
+
 	return entry(pc, ui) || !(--ui->max_stack) ?
 	       DWARF_CB_ABORT : DWARF_CB_OK;
 }
-- 
2.13.0

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH] perf report: fix off-by-one for non-activation frames
  2017-05-15 15:04 [PATCH] perf report: fix off-by-one for non-activation frames Milian Wolff
@ 2017-05-15 15:13 ` Milian Wolff
  2017-05-16  1:57   ` Namhyung Kim
  2017-06-16  6:14 ` Jan Kratochvil
  1 sibling, 1 reply; 13+ messages in thread
From: Milian Wolff @ 2017-05-15 15:13 UTC (permalink / raw)
  To: Milian Wolff
  Cc: Linux-kernel, linux-perf-users, Milian Wolff,
	Arnaldo Carvalho de Melo, David Ahern, Namhyung Kim,
	Peter Zijlstra, Yao Jin

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

On Monday, May 15, 2017 5:04:44 PM CEST Milian Wolff wrote:
> As the documentation for dwfl_frame_pc says, frames that
> are no activation frames need to have their program counter
> decremented by one to properly find the function of the caller.

Note that this leaves the perf build against libunwind in the current, broken 
state. I do not know how to detect the activation property there. Does anyone 
else? See elfutils source code for what it is doing:

https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/
dwfl_frame_pc.c;h=296c815b9c73f42d79ac1778d2a0c420b89ee4eb;hb=HEAD

Cheers
-- 
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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] perf report: fix off-by-one for non-activation frames
  2017-05-15 15:13 ` Milian Wolff
@ 2017-05-16  1:57   ` Namhyung Kim
  2017-05-16  9:00     ` Milian Wolff
  0 siblings, 1 reply; 13+ messages in thread
From: Namhyung Kim @ 2017-05-16  1:57 UTC (permalink / raw)
  To: Milian Wolff
  Cc: Linux-kernel, linux-perf-users, Arnaldo Carvalho de Melo,
	David Ahern, Peter Zijlstra, Yao Jin, kernel-team

On Mon, May 15, 2017 at 05:13:06PM +0200, Milian Wolff wrote:
> On Monday, May 15, 2017 5:04:44 PM CEST Milian Wolff wrote:
> > As the documentation for dwfl_frame_pc says, frames that
> > are no activation frames need to have their program counter
> > decremented by one to properly find the function of the caller.
> 
> Note that this leaves the perf build against libunwind in the current, broken 
> state. I do not know how to detect the activation property there. Does anyone 
> else? See elfutils source code for what it is doing:
> 
> https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/
> dwfl_frame_pc.c;h=296c815b9c73f42d79ac1778d2a0c420b89ee4eb;hb=HEAD

It seems that you can use unw_is_signal_frame().

Thanks,
Namhyung

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] perf report: fix off-by-one for non-activation frames
  2017-05-16  1:57   ` Namhyung Kim
@ 2017-05-16  9:00     ` Milian Wolff
  0 siblings, 0 replies; 13+ messages in thread
From: Milian Wolff @ 2017-05-16  9:00 UTC (permalink / raw)
  To: Namhyung Kim
  Cc: Linux-kernel, linux-perf-users, Arnaldo Carvalho de Melo,
	David Ahern, Peter Zijlstra, Yao Jin, kernel-team

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

On Dienstag, 16. Mai 2017 03:57:53 CEST Namhyung Kim wrote:
> On Mon, May 15, 2017 at 05:13:06PM +0200, Milian Wolff wrote:
> > On Monday, May 15, 2017 5:04:44 PM CEST Milian Wolff wrote:
> > > As the documentation for dwfl_frame_pc says, frames that
> > > are no activation frames need to have their program counter
> > > decremented by one to properly find the function of the caller.
> > 
> > Note that this leaves the perf build against libunwind in the current,
> > broken state. I do not know how to detect the activation property there.
> > Does anyone else? See elfutils source code for what it is doing:
> > 
> > https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/
> > dwfl_frame_pc.c;h=296c815b9c73f42d79ac1778d2a0c420b89ee4eb;hb=HEAD
> 
> It seems that you can use unw_is_signal_frame().

Thank you! The v2 patch I just sent now uses that and it seems to work 
reliably in my quick test.

Cheers

-- 
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 --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-05-15 15:04 [PATCH] perf report: fix off-by-one for non-activation frames Milian Wolff
  2017-05-15 15:13 ` Milian Wolff
@ 2017-06-16  6:14 ` Jan Kratochvil
  2017-06-16 11:51   ` Milian Wolff
  1 sibling, 1 reply; 13+ messages in thread
From: Jan Kratochvil @ 2017-06-16  6:14 UTC (permalink / raw)
  To: Milian Wolff
  Cc: Linux-kernel, linux-perf-users, Arnaldo Carvalho de Melo,
	David Ahern, Namhyung Kim, Peter Zijlstra, Yao Jin, Jiri Olsa

On Mon, 15 May 2017 17:04:44 +0200, Milian Wolff wrote:

commit 1982ad48fc82c284a5cc55697a012d3357e84d01
Author: Milian Wolff <milian.wolff@kdab.com>
Date:   Wed May 24 15:21:25 2017 +0900

> --- a/tools/perf/util/unwind-libdw.c
> +++ b/tools/perf/util/unwind-libdw.c
> @@ -168,12 +168,16 @@ frame_callback(Dwfl_Frame *state, void *arg)
...
> +	if (!isactivation)
> +		--pc;
> +

FYI I find it as a regression a bit:

perf-4.11.4-200.fc25.x86_64
                  30c563 gdb_main (/usr/libexec/gdb)
                   fae48 main (/usr/libexec/gdb)
   0x000055555564ee43 <+51>:    callq  0x55555585f340 <gdb_main(captured_main_args*)>
   0x000055555564ee48 <+56>:    mov    0x18(%rsp),%rcx

perf-4.12.0-0.rc5.git0.1.fc27.x86_64
                  39e32e gdb_main (/usr/libexec/gdb)
                  10b6fa main (/usr/libexec/gdb)
   0x000055555565f6f6 <+54>:    callq  0x5555558f17a0 <gdb_main(captured_main_args*)>
   0x000055555565f6fb <+59>:    mov    0x18(%rsp),%rcx

In backtraces it is correct to show the source line of the calling line - as
perf does now after your fix - but one still should report PC address of the
start of the next instruction.  At least this is what debuggers are used to
do:

#9  gdb_main (args=0x7fffffffe2e0) at ../../gdb/main.c:1257
#10 0x000055555565f6fb in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:40
   0x000055555565f6f6 <+54>:	callq  0x5555558f17a0 <gdb_main(captured_main_args*)>
=> 0x000055555565f6fb <+59>:	mov    0x18(%rsp),%rcx
Line 40 of "../../gdb/gdb.c" starts at address 0x55555565f6f6 <main(int, char**)+54> and ends at 0x55555565f6fb <main(int, char**)+59>.
Line 41 of "../../gdb/gdb.c" starts at address 0x55555565f6fb <main(int, char**)+59> and ends at 0x55555565f715.

You see "gdb.c:40" and 0x000055555565f6fb in the backtrace despite
0x55555565f6fb is already line 41.

This is also why elfutils reports separately PC and 'isactivation' flag.
Instead of just reporting decreased PC.


Jan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-16  6:14 ` Jan Kratochvil
@ 2017-06-16 11:51   ` Milian Wolff
  2017-06-16 11:57     ` Jan Kratochvil
  0 siblings, 1 reply; 13+ messages in thread
From: Milian Wolff @ 2017-06-16 11:51 UTC (permalink / raw)
  To: Jan Kratochvil
  Cc: Linux-kernel, linux-perf-users, Arnaldo Carvalho de Melo,
	David Ahern, Namhyung Kim, Peter Zijlstra, Yao Jin, Jiri Olsa

On Freitag, 16. Juni 2017 08:14:56 CEST Jan Kratochvil wrote:
> On Mon, 15 May 2017 17:04:44 +0200, Milian Wolff wrote:
> 
> commit 1982ad48fc82c284a5cc55697a012d3357e84d01
> Author: Milian Wolff <milian.wolff@kdab.com>
> Date:   Wed May 24 15:21:25 2017 +0900
> 
> > --- a/tools/perf/util/unwind-libdw.c
> > +++ b/tools/perf/util/unwind-libdw.c
> > @@ -168,12 +168,16 @@ frame_callback(Dwfl_Frame *state, void *arg)
> 
> ...
> 
> > +	if (!isactivation)
> > +		--pc;
> > +
> 
> FYI I find it as a regression a bit:
> 
> perf-4.11.4-200.fc25.x86_64
>                   30c563 gdb_main (/usr/libexec/gdb)
>                    fae48 main (/usr/libexec/gdb)
>    0x000055555564ee43 <+51>:    callq  0x55555585f340
> <gdb_main(captured_main_args*)> 0x000055555564ee48 <+56>:    mov   
> 0x18(%rsp),%rcx
> 
> perf-4.12.0-0.rc5.git0.1.fc27.x86_64
>                   39e32e gdb_main (/usr/libexec/gdb)
>                   10b6fa main (/usr/libexec/gdb)
>    0x000055555565f6f6 <+54>:    callq  0x5555558f17a0
> <gdb_main(captured_main_args*)> 0x000055555565f6fb <+59>:    mov   
> 0x18(%rsp),%rcx
> 
> In backtraces it is correct to show the source line of the calling line - as
> perf does now after your fix - but one still should report PC address of
> the start of the next instruction.  At least this is what debuggers are
> used to do:
> 
> #9  gdb_main (args=0x7fffffffe2e0) at ../../gdb/main.c:1257
> #10 0x000055555565f6fb in main (argc=<optimized out>, argv=<optimized out>)
> at ../../gdb/gdb.c:40 0x000055555565f6f6 <+54>:	callq  0x5555558f17a0
> <gdb_main(captured_main_args*)> => 0x000055555565f6fb <+59>:	mov   
> 0x18(%rsp),%rcx
> Line 40 of "../../gdb/gdb.c" starts at address 0x55555565f6f6 <main(int,
> char**)+54> and ends at 0x55555565f6fb <main(int, char**)+59>. Line 41 of
> "../../gdb/gdb.c" starts at address 0x55555565f6fb <main(int, char**)+59>
> and ends at 0x55555565f715.
> 
> You see "gdb.c:40" and 0x000055555565f6fb in the backtrace despite
> 0x55555565f6fb is already line 41.
> 
> This is also why elfutils reports separately PC and 'isactivation' flag.
> Instead of just reporting decreased PC.

Excuse me, but I'm having trouble following you. The non-GDB backtraces you 
are pasting do not show srcline information. So what exactly is broken? Can 
you show me the differences a bit more clearly? Maybe paste the perf output 
you get now and highlight what you'd expect instead? Best would be an 
accompanying test case that I can use to improve the situation, if possible?

Thanks

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-16 11:51   ` Milian Wolff
@ 2017-06-16 11:57     ` Jan Kratochvil
  2017-06-16 19:54       ` Milian Wolff
  0 siblings, 1 reply; 13+ messages in thread
From: Jan Kratochvil @ 2017-06-16 11:57 UTC (permalink / raw)
  To: Milian Wolff
  Cc: Linux-kernel, linux-perf-users, Arnaldo Carvalho de Melo,
	David Ahern, Namhyung Kim, Peter Zijlstra, Yao Jin, Jiri Olsa

On Fri, 16 Jun 2017 13:51:37 +0200, Milian Wolff wrote:
> > perf-4.12.0-0.rc5.git0.1.fc27.x86_64
> >                   39e32e gdb_main (/usr/libexec/gdb)
> >                   10b6fa main (/usr/libexec/gdb)
> >    0x000055555565f6f6 <+54>:    callq  0x5555558f17a0 <gdb_main(captured_main_args*)
> >    0x000055555565f6fb <+59>:    mov    0x18(%rsp),%rcx
[...]
> Excuse me, but I'm having trouble following you. The non-GDB backtraces you 
> are pasting do not show srcline information. So what exactly is broken?

There is broken that perf now reports address 10b6fa (corresponding to
relocated address 0x000055555565f6fa) but there is no instruction on address
0x000055555565f6fa.  If you 'objdump -d' it you cannot find any instruction on
adress 0x000055555565f6fa (or on address 0x10b6fa).  There is instruction on
address 0x000055555565f6fb.


> Maybe paste the perf output you get now and highlight what you'd expect
> instead?

Actual:
                  39e32e gdb_main (/usr/libexec/gdb)
                  10b6fa main (/usr/libexec/gdb)
Expected:
                  39e32f gdb_main (/usr/libexec/gdb)
                  10b6fb main (/usr/libexec/gdb)

I agree perf needs to calculate with 39e32e and 10b6fa.  But it should display
to user 39e32f and 10b6fb.


Jan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-16 11:57     ` Jan Kratochvil
@ 2017-06-16 19:54       ` Milian Wolff
  2017-06-17  7:56         ` Namhyung Kim
  0 siblings, 1 reply; 13+ messages in thread
From: Milian Wolff @ 2017-06-16 19:54 UTC (permalink / raw)
  To: Jan Kratochvil
  Cc: Linux-kernel, linux-perf-users, Arnaldo Carvalho de Melo,
	David Ahern, Namhyung Kim, Peter Zijlstra, Yao Jin, Jiri Olsa

On Freitag, 16. Juni 2017 13:57:44 CEST Jan Kratochvil wrote:
> On Fri, 16 Jun 2017 13:51:37 +0200, Milian Wolff wrote:
> > > perf-4.12.0-0.rc5.git0.1.fc27.x86_64
> > > 
> > >                   39e32e gdb_main (/usr/libexec/gdb)
> > >                   10b6fa main (/usr/libexec/gdb)
> > >    
> > >    0x000055555565f6f6 <+54>:    callq  0x5555558f17a0
> > >    <gdb_main(captured_main_args*) 0x000055555565f6fb <+59>:    mov   
> > >    0x18(%rsp),%rcx
> 
> [...]
> 
> > Excuse me, but I'm having trouble following you. The non-GDB backtraces
> > you
> > are pasting do not show srcline information. So what exactly is broken?
> 
> There is broken that perf now reports address 10b6fa (corresponding to
> relocated address 0x000055555565f6fa) but there is no instruction on address
> 0x000055555565f6fa.  If you 'objdump -d' it you cannot find any instruction
> on adress 0x000055555565f6fa (or on address 0x10b6fa).  There is
> instruction on address 0x000055555565f6fb.
> 
> > Maybe paste the perf output you get now and highlight what you'd expect
> > instead?
> 
> Actual:
>                   39e32e gdb_main (/usr/libexec/gdb)
>                   10b6fa main (/usr/libexec/gdb)
> Expected:
>                   39e32f gdb_main (/usr/libexec/gdb)
>                   10b6fb main (/usr/libexec/gdb)
> 
> I agree perf needs to calculate with 39e32e and 10b6fa.  But it should
> display to user 39e32f and 10b6fb.

Hmmm this will require some more changes throughout the stack then. I.e. we'll 
have to remember the "isactivation" flag along with the original IP, and only 
apply the offset then when we query for inliners or srcline information. Maybe 
I can pull that off somehow in the patch series I'm working on currently, 
which refactors the whole inline/srcline/callchain logic anyways.

I don't see an easy way to fix the behavior. Does anyone else? So how do we 
deal with this situation in the interim? I'd prefer we keep the current 
"broken" state, as I consider it less broken than what we had before... I 
guess some of the core perf developers should decide how to handle this.

Thanks

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-16 19:54       ` Milian Wolff
@ 2017-06-17  7:56         ` Namhyung Kim
  2017-06-17  8:04           ` Jan Kratochvil
  0 siblings, 1 reply; 13+ messages in thread
From: Namhyung Kim @ 2017-06-17  7:56 UTC (permalink / raw)
  To: Milian Wolff
  Cc: Jan Kratochvil, linux-kernel@vger.kernel.org, linux-perf-users,
	Arnaldo Carvalho de Melo, David Ahern, Peter Zijlstra, Yao Jin,
	Jiri Olsa

On Sat, Jun 17, 2017 at 4:54 AM, Milian Wolff <milian.wolff@kdab.com> wrote:
> On Freitag, 16. Juni 2017 13:57:44 CEST Jan Kratochvil wrote:
>> On Fri, 16 Jun 2017 13:51:37 +0200, Milian Wolff wrote:
>> > > perf-4.12.0-0.rc5.git0.1.fc27.x86_64
>> > >
>> > >                   39e32e gdb_main (/usr/libexec/gdb)
>> > >                   10b6fa main (/usr/libexec/gdb)
>> > >
>> > >    0x000055555565f6f6 <+54>:    callq  0x5555558f17a0
>> > >    <gdb_main(captured_main_args*) 0x000055555565f6fb <+59>:    mov
>> > >    0x18(%rsp),%rcx
>>
>> [...]
>>
>> > Excuse me, but I'm having trouble following you. The non-GDB backtraces
>> > you
>> > are pasting do not show srcline information. So what exactly is broken?
>>
>> There is broken that perf now reports address 10b6fa (corresponding to
>> relocated address 0x000055555565f6fa) but there is no instruction on address
>> 0x000055555565f6fa.  If you 'objdump -d' it you cannot find any instruction
>> on adress 0x000055555565f6fa (or on address 0x10b6fa).  There is
>> instruction on address 0x000055555565f6fb.
>>
>> > Maybe paste the perf output you get now and highlight what you'd expect
>> > instead?
>>
>> Actual:
>>                   39e32e gdb_main (/usr/libexec/gdb)
>>                   10b6fa main (/usr/libexec/gdb)
>> Expected:
>>                   39e32f gdb_main (/usr/libexec/gdb)
>>                   10b6fb main (/usr/libexec/gdb)
>>
>> I agree perf needs to calculate with 39e32e and 10b6fa.  But it should
>> display to user 39e32f and 10b6fb.
>
> Hmmm this will require some more changes throughout the stack then. I.e. we'll
> have to remember the "isactivation" flag along with the original IP, and only
> apply the offset then when we query for inliners or srcline information. Maybe
> I can pull that off somehow in the patch series I'm working on currently,
> which refactors the whole inline/srcline/callchain logic anyways.
>
> I don't see an easy way to fix the behavior. Does anyone else? So how do we
> deal with this situation in the interim? I'd prefer we keep the current
> "broken" state, as I consider it less broken than what we had before... I
> guess some of the core perf developers should decide how to handle this.

Not sure whether it needs be fixed or not.  If we fix it, srcline and
address would not match so it can give its own confusion to users.
Ideally it should display an addressof the instruction before the
address IMHO.

Thanks,
Namhyung

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-17  7:56         ` Namhyung Kim
@ 2017-06-17  8:04           ` Jan Kratochvil
  2017-06-17 11:13             ` Milian Wolff
  0 siblings, 1 reply; 13+ messages in thread
From: Jan Kratochvil @ 2017-06-17  8:04 UTC (permalink / raw)
  To: Namhyung Kim
  Cc: Milian Wolff, linux-kernel@vger.kernel.org, linux-perf-users,
	Arnaldo Carvalho de Melo, David Ahern, Peter Zijlstra, Yao Jin,
	Jiri Olsa

On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote:
> Not sure whether it needs be fixed or not.  If we fix it, srcline and
> address would not match so it can give its own confusion to users.
> Ideally it should display an addressof the instruction before the
> address IMHO.

One can figure million ways how it can behave and each one has its pros and
cons.  I was just describing the current behavior of GDB and LLDB which people
are used to already.


Jan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-17  8:04           ` Jan Kratochvil
@ 2017-06-17 11:13             ` Milian Wolff
  2017-06-19 18:59               ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 13+ messages in thread
From: Milian Wolff @ 2017-06-17 11:13 UTC (permalink / raw)
  To: Jan Kratochvil
  Cc: Namhyung Kim, linux-kernel@vger.kernel.org, linux-perf-users,
	Arnaldo Carvalho de Melo, David Ahern, Peter Zijlstra, Yao Jin,
	Jiri Olsa

On Samstag, 17. Juni 2017 10:04:02 CEST Jan Kratochvil wrote:
> On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote:
> > Not sure whether it needs be fixed or not.  If we fix it, srcline and
> > address would not match so it can give its own confusion to users.
> > Ideally it should display an addressof the instruction before the
> > address IMHO.
> 
> One can figure million ways how it can behave and each one has its pros and
> cons.  I was just describing the current behavior of GDB and LLDB which
> people are used to already.

Personally, I agree with Jan that we should mimick existing tool's behavior. I 
just fear that it's not trivial to do it with the current code base...

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-17 11:13             ` Milian Wolff
@ 2017-06-19 18:59               ` Arnaldo Carvalho de Melo
  2017-07-04  7:59                 ` Milian Wolff
  0 siblings, 1 reply; 13+ messages in thread
From: Arnaldo Carvalho de Melo @ 2017-06-19 18:59 UTC (permalink / raw)
  To: Milian Wolff
  Cc: Jan Kratochvil, Namhyung Kim, linux-kernel@vger.kernel.org,
	linux-perf-users, David Ahern, Peter Zijlstra, Yao Jin,
	Jiri Olsa

Em Sat, Jun 17, 2017 at 01:13:11PM +0200, Milian Wolff escreveu:
> On Samstag, 17. Juni 2017 10:04:02 CEST Jan Kratochvil wrote:
> > On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote:
> > > Not sure whether it needs be fixed or not.  If we fix it, srcline and
> > > address would not match so it can give its own confusion to users.
> > > Ideally it should display an addressof the instruction before the
> > > address IMHO.
> > 
> > One can figure million ways how it can behave and each one has its pros and
> > cons.  I was just describing the current behavior of GDB and LLDB which
> > people are used to already.
> 
> Personally, I agree with Jan that we should mimick existing tool's behavior. I 
> just fear that it's not trivial to do it with the current code base...

But we agree it is a worthwhile change (have backtraces in perf match
what gdb, etc show), right?

If you can, please try to do this, your attempt will help us understand
more the extent of the changes needed and perhaps someonw can come up
with simplifications...

- Arnaldo

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: perf report: fix off-by-one for non-activation frames
  2017-06-19 18:59               ` Arnaldo Carvalho de Melo
@ 2017-07-04  7:59                 ` Milian Wolff
  0 siblings, 0 replies; 13+ messages in thread
From: Milian Wolff @ 2017-07-04  7:59 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Jan Kratochvil, Namhyung Kim, linux-kernel@vger.kernel.org,
	linux-perf-users, David Ahern, Peter Zijlstra, Yao Jin,
	Jiri Olsa

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

On Monday, June 19, 2017 8:59:39 PM CEST Arnaldo Carvalho de Melo wrote:
> Em Sat, Jun 17, 2017 at 01:13:11PM +0200, Milian Wolff escreveu:
> > On Samstag, 17. Juni 2017 10:04:02 CEST Jan Kratochvil wrote:
> > > On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote:
> > > > Not sure whether it needs be fixed or not.  If we fix it, srcline and
> > > > address would not match so it can give its own confusion to users.
> > > > Ideally it should display an addressof the instruction before the
> > > > address IMHO.
> > > 
> > > One can figure million ways how it can behave and each one has its pros
> > > and
> > > cons.  I was just describing the current behavior of GDB and LLDB which
> > > people are used to already.
> > 
> > Personally, I agree with Jan that we should mimick existing tool's
> > behavior. I just fear that it's not trivial to do it with the current
> > code base...
> But we agree it is a worthwhile change (have backtraces in perf match
> what gdb, etc show), right?
> 
> If you can, please try to do this, your attempt will help us understand
> more the extent of the changes needed and perhaps someonw can come up
> with simplifications...

Sorry for the (long) delay, but I'm sadly busy on other things right now. I 
have this on my radar and will try to find time to look into it. But it 
probably won't happen before end of July. If this is urgent, maybe someone 
else needs to look into it before me.

Cheers

-- 
Milian Wolff | milian.wolff@kdab.com | Senior 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: 3826 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2017-07-04  7:59 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-15 15:04 [PATCH] perf report: fix off-by-one for non-activation frames Milian Wolff
2017-05-15 15:13 ` Milian Wolff
2017-05-16  1:57   ` Namhyung Kim
2017-05-16  9:00     ` Milian Wolff
2017-06-16  6:14 ` Jan Kratochvil
2017-06-16 11:51   ` Milian Wolff
2017-06-16 11:57     ` Jan Kratochvil
2017-06-16 19:54       ` Milian Wolff
2017-06-17  7:56         ` Namhyung Kim
2017-06-17  8:04           ` Jan Kratochvil
2017-06-17 11:13             ` Milian Wolff
2017-06-19 18:59               ` Arnaldo Carvalho de Melo
2017-07-04  7:59                 ` Milian Wolff

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).