perf annotate: Numeric assembly labels cause incorrect annotation

A perf annotate of a kernel function written in assembly shows very strange percentages:

: _GLOBAL(__copy_tofrom_user_base)

...

: addi r3,r3,1
99.67 : c00000000004d78c: addi r3,r3,1

         :
    0.00 :      1:      bf      cr7*4+2,2f
    0.07 :      c00000000004d790:       bne-    cr7,c00000000004d7a4
         :      err1;   lhz     r0,0(r4)
    0.00 :      c00000000004d794:       lhz     r0,0(r4)
         :              addi    r4,r4,2
    0.00 :      c00000000004d798:       addi    r4,r4,2
         :      err1;   sth     r0,0(r3)
    0.00 :      c00000000004d79c:       sth     r0,0(r3)
         :              addi    r3,r3,2
   99.60 :      c00000000004d7a0:       addi    r3,r3,2
         :
    0.00 :      2:      bf      cr7*4+1,3f
    0.12 :      c00000000004d7a4:       ble-    cr7,c00000000004d7b8
         :      err1;   lwz     r0,0(r4)
    0.00 :      c00000000004d7a8:       lwz     r0,0(r4)
         :              addi    r4,r4,4
    0.00 :      c00000000004d7ac:       addi    r4,r4,4
         :      err1;   stw     r0,0(r3)
    0.00 :      c00000000004d7b0:       stw     r0,0(r3)
         :              addi    r3,r3,4

99.48 : c00000000004d7b4: addi r3,r3,4

~300% in one function. Urgh.

This is caused by the way we parse objdump -S output, eg:

        addi    r3,r3,1

c00000000004d78c: addi r3,r3,1

1: bf cr7*4+2,2f
c00000000004d790: bne- cr7,c00000000004d7a4

We assume the asm label (1:) is an address, compute a bogus offset into the function and then screw up the matching of samples to lines. I notice this also fails with c inline assembly in a similar manner.

We already have a sanity check that the address is not beyond the end of the function, so add a check against the start too.

Signed-off-by Anton Blanchard <[email protected]>

A perf annotate of a kernel function written in assembly shows very strange percentages:

: _GLOBAL(__copy_tofrom_user_base)

...

: addi r3,r3,1
99.67 : c00000000004d78c: addi r3,r3,1

         :
    0.00 :      1:      bf      cr7*4+2,2f
    0.07 :      c00000000004d790:       bne-    cr7,c00000000004d7a4
         :      err1;   lhz     r0,0(r4)
    0.00 :      c00000000004d794:       lhz     r0,0(r4)
         :              addi    r4,r4,2
    0.00 :      c00000000004d798:       addi    r4,r4,2
         :      err1;   sth     r0,0(r3)
    0.00 :      c00000000004d79c:       sth     r0,0(r3)
         :              addi    r3,r3,2
   99.60 :      c00000000004d7a0:       addi    r3,r3,2
         :
    0.00 :      2:      bf      cr7*4+1,3f
    0.12 :      c00000000004d7a4:       ble-    cr7,c00000000004d7b8
         :      err1;   lwz     r0,0(r4)
    0.00 :      c00000000004d7a8:       lwz     r0,0(r4)
         :              addi    r4,r4,4
    0.00 :      c00000000004d7ac:       addi    r4,r4,4
         :      err1;   stw     r0,0(r3)
    0.00 :      c00000000004d7b0:       stw     r0,0(r3)
         :              addi    r3,r3,4

99.48 : c00000000004d7b4: addi r3,r3,4

~300% in one function. Urgh.

This is caused by the way we parse objdump -S output, eg:

        addi    r3,r3,1

c00000000004d78c: addi r3,r3,1

1: bf cr7*4+2,2f
c00000000004d790: bne- cr7,c00000000004d7a4

We assume the asm label (1:) is an address, compute a bogus offset into the function and then screw up the matching of samples to lines. I notice this also fails with c inline assembly in a similar manner.

We already have a sanity check that the address is not beyond the end of the function, so add a check against the start too.

Signed-off-by Anton Blanchard <[email protected]>

---
Cc: <[email protected]>

Index: linux-tip/tools/perf/util/annotate.c
===================================================================

tools/perf/util/annotate.c +1 -1

@@ -244,7 +244,7 @@ static int symbol__parse_objdump_line(st
 		    end = map__rip_2objdump(map, sym->end);
 
 		offset = line_ip - start;
-		if (offset < 0 || (u64)line_ip > end)
+		if (offset < 0 || (u64)line_ip < start || (u64)line_ip > end)
 			offset = -1;
 	}
 

Em Tue, Feb 07, 2012 at 02:55:35PM +1100, Anton Blanchard escreveu:

Quoted 3 lines

A perf annotate of a kernel function written in assembly shows very strange percentages:

Thanks! I think this is the same problem Mike Galbraith noticed and reported me (I guess that was in a private message), Mike, can you please test it so that I can add more Foo-by stamps to this one?

Quoted 8 lines · Arnaldo Carvalho de Melo

Em Tue, Feb 07, 2012 at 02:55:35PM +1100, Anton Blanchard escreveu:

Quoted 3 lines

A perf annotate of a kernel function written in assembly shows very strange percentages:

Thanks! I think this is the same problem Mike Galbraith noticed and reported me (I guess that was in a private message), Mike, can you please test it so that I can add more Foo-by stamps to this one?

Sorry for the slow response (bz bz).

I don't see that problem, but perf top annotation isn't working properly in tip at least. It seems to have forgotten how to average, seems to be clearing hit counts at every screen refresh or something.

Quoted 4 lines · Mike Galbraith

I don't see that problem, but perf top annotation isn't working properly in tip at least. It seems to have forgotten how to average, seems to be clearing hit counts at every screen refresh or something.

hm, seems to work fine here. We used to have such a bug recently (as of a few weeks [days?] ago), but latest -tip does not show those symptoms.

Quoted 12 lines · Mike Galbraith

Quoted 8 lines · Arnaldo Carvalho de Melo

Em Tue, Feb 07, 2012 at 02:55:35PM +1100, Anton Blanchard escreveu:

Quoted 3 lines

A perf annotate of a kernel function written in assembly shows very strange percentages:

Thanks! I think this is the same problem Mike Galbraith noticed and reported me (I guess that was in a private message), Mike, can you please test it so that I can add more Foo-by stamps to this one?

Sorry for the slow response (bz bz).

Quoted 4 lines

I don't see that problem, but perf top annotation isn't working properly in tip at least. It seems to have forgotten how to average, seems to be clearing hit counts at every screen refresh or something.

hm, seems to work fine here. We used to have such a bug recently (as of a few weeks [days?] ago), but latest -tip does not show those symptoms.