[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oprofile-list
Subject:    Help needed from OProfile community
From:       Maynard Johnson <maynardj () us ! ibm ! com>
Date:       2012-01-26 21:07:30
Message-ID: 4F21C092.1020708 () us ! ibm ! com
[Download RAW message or body]

In the past several weeks, I've found and fixed several oprofile bugs and posted 
patches to the mailing list (see below).  The rule in this community is that 
*all* non-trivial patches must be reviewed by at least one other community 
member, so I am asking for help from anyone who can test and/or review the 
patches.  Looking back on my postings, I realize I did a poor job of describing 
what the patches were fixing, so I've attempted to make that clear below.  I 
trust that others have seen at least some of these symptoms before and may be 
willing to do some testing (and code review, if you can).

Any and all feedback is welcome.  Thank you!

1. [PATCH] Fix debuginfo processing for non-ppc64 architectures
	Posted Jan 6	
	Symptom:  If shared libraries have been stripped of symbol information, users 
must make
	debuginfo files available that contain the symbol information for those 
libraries so that
	opreport can attribute samples to symbols for those libraries.  But in a 
prelinked environment
	(e.g., RHEL, Fedora), opreport does not correctly process the debuginfo files, 
thus generating
	report data such as the following:
	samples  %        image name               symbol name
	1531      6.2205  libcairo.so.2.11000.2    /usr/lib64/libcairo.so.2.11000.2

	In the example given above, the debuginfo package corresponding to the cairo 
package
	has been installed.  Note that this problem only occurs where the shared library is
	completely stripped of symbol information.  And on RHEL and Fedora, basic 
symbol information
	is retained in the runtime library, so this symptom does not appear with 
samples taken in libc.

2. [PATCH] Fix debuginfo processing for ppc64 architecture
	Posted Jan 6
	Symptom: With patch #1 applied, address-to-symbol resolution worked properly in 
prelinked
	environments on ppc64 and Intel architectures.  However, on ppc64, 
"--debug-info" reports
	did not show correct source file/line number info.  Bad data looked like the 
following:

	samples  %        linenr info                 image name               symbol name
	1491      6.0580  cairo-tee-surface.c:0       libcairo.so.2.11000.2 
00000145.plt_call.strchr@@GLIBC_2.3+0

	And good output, with the patch applied, looks like this:

	samples  %        linenr info                 image name               symbol name
	327       1.3286  cairo-bentley-ottmann.c:1723 libcairo.so.2.11000.2 
._cairo_bentley_ottmann_tessellate_polygon
	51        0.2072  cairo-surface.c:632         libcairo.so.2.11000.2 
.cairo_surface_destroy

3. [PATCH] Fix debuginfo processing to handle no symbol info in debuginfo file
	Posted Jan 12
	Symptom: Certain system libs (notably, libc) on certain distros (RHEL, Fedora) 
retain basic
	symbol information, but their corresponding debuginfo files have only debug 
data -- i.e., no
	basic symbol info.  opreport does not handle that situation properly, resulting 
in "--debug-info"
	reports that look like the following:

	samples  %        linenr info                 image name               symbol name
	67982    14.7813  (no location information)   libc-2.12.so             .__random
	18665     4.0583  (no location information)   libc-2.12.so             ._itoa_word

	And good output, with patch #3 applied, looks like this:

	samples  %        linenr info                 image name               symbol name
	67982    14.7813  random.c:293                libc-2.12.so             .__random
	18665     4.0583  _itoa.c:176                 libc-2.12.so             ._itoa_word

4. [PATCH] Discard user context kernel samples for which we have no app_cookie
	Posted Jan 19
	Symptom: Under certain conditions, samples are not attributed to the appropriate
	app name.  If profiling is done with --separate=lib,thread[,other-options] and then
	a report is generated using a tgid or tid specification to see profile data for one
	particular process or thread, you may see anomalies like that shown below.  Note
	the line with "ext3" under the 'app name' column, when all other lines (rightly)
	have "spin".

	samples  %        image name               app name                 symbol name
	1018088  99.8455  spin                     spin                     .spin
	1566      0.1536  ext3                     spin                     /ext3
	4        3.9e-04  ext3                     ext3                     /ext3
	1        9.8e-05  ld-2.12.1.so             spin 
._dl_map_object_from_fd
	1        9.8e-05  ld-2.12.1.so             spin 
._dl_relocate_object
	1        9.8e-05  ld-2.12.1.so             spin 
.check_match.8837
	1        9.8e-05  libc-2.12.1.so           spin                     ._IO_cleanup


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
[prev in list] [next in list] [prev in thread] [next in thread]