Help needed from OProfile community (re-formatted)

[Maynard J. <may...@us...>]

Sorry for the poor formatting of my first note on this subject.  This note is
the same content, just formatted nicer, so you can delete the original.
----------------------------------------------------------------------

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 testand/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 othershave seen at least some of these symptoms before and may be
willing to do some testing (and codereview, 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 
<mailto: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
     debugdata -- 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