Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 355178

Summary:

OProfile summary reports line numbers in the wrong files, when inlining and -O2 or -O3 is used

Product:

z_Archived

Reporter:

Corey Ashford <cjashfor>

Component:

LinuxTools

Assignee:

Roland Grunberg <rgrunber>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

kksebasti, wainersm

Version:

unspecified

Target Milestone:

---

Hardware:

All

OS:

Linux

See Also:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=359076

Whiteboard:

Attachments:

Description	Flags
Screen shot showing the incorrect line number reporting. "3.77% on line 41"	none
main file for the test case	none
.h file which defines the inline function	none

Description Corey Ashford

2011-08-18 19:49:37 EDT

Build Identifier: I20110613-1736

OProfile reports line numbers that come from inlined functions as part of the inline caller, rather than the callee.  For example,
Function A in file 1 calls inlined Function B in file 2.
The OProfile results show the line numbers from B in file 2, but report them as being in Function A in file 1.

Looking at the code in the plug-in Maynard Johnson, one of the maintainers of OProfile, noted that it isn't passing the '--debug-info' option, which provides an easier way of obtaining this mapping of IP addresses back to accurate line numbers in the source.

Presumably, the OProfile plug-in is doing this mapping itself and is getting it wrong for at least some cases of inlined functions.

I am going to attach a screen shot and a simple example that demonstrates this problem.

Reproducible: Always

Steps to Reproduce:
1. Compile the provided example at -O2 or -O3
2. Run it with the OProfile plug-in
3. Note that the results show a line 41 in a sample_c.c, which has only 30 lines total.

Comment 1 Corey Ashford

2011-08-18 19:51:11 EDT

Created attachment 201759 [details]
Screen shot showing the incorrect line number reporting.  "3.77% on line 41"

Comment 2 Corey Ashford

2011-08-18 19:52:02 EDT

Created attachment 201760 [details]
main file for the test case

Comment 3 Corey Ashford

2011-08-18 19:53:00 EDT

Created attachment 201761 [details]
.h file which defines the inline function

Comment 4 Roland Grunberg

2011-09-26 15:31:23 EDT

I've committed http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/?id=f71494378039c6c7733a2f1a876679568a40846e to rely on opreport for location of symbols in the source. When I run opreport after reproducing I see the following :

CPU: Intel Architectural Perfmon, speed 1600 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
vma      samples  %        linenr info                 image name               symbol name
08048310 839      59.0429  sample_c.c:20               test_summary             main
  08048320 109      12.9917  do_nothing.h:41
  08048327 729      86.8892  sample_c.c:25
  0804832c 1         0.1192  sample_c.c:23
08048420 580      40.8163  sample_c.c:16               test_summary             local_do_nothing
  08048420 1         0.1724  sample_c.c:16
  08048427 579      99.8276  sample_c.c:17
  
  So it seems that even though the sample shows up under main (sample_c.c:20), the source location refers to do_nothing.h:41. I could have each sample in the view list the file name to which it refers as well, although double clicking on the sample should take the user to the desired location.

Comment 5 Corey Ashford

2011-09-26 20:07:39 EDT

Great!

Looking through the patch, it appears you didn't need to add the -g | --debug-info switch to opreport to get the file and line # info?

Comment 6 Roland Grunberg

2011-09-27 10:13:14 EDT

Currently the plugin calls addr2line on the set of addresses provided in the XML. Initially it looked like -g didn't provide file info for all possible samples. However, it seems that for a given sample, if it resides in the same file as it's parent, the file is omitted, which makes sense.

I'll file a bug against that. Marking this as closed.