Bug 131417 - opreport does not use preferred symbol names
opreport does not use preferred symbol names
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: oprofile (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: William Cohen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-01 02:29 EDT by Ulrich Drepper
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 0.8.1-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-22 14:18:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to select more appropriate symbol name (1.76 KB, patch)
2004-09-17 13:33 EDT, William Cohen
no flags Details | Diff

  None (edit)
Description Ulrich Drepper 2004-09-01 02:29:30 EDT
Description of problem:
The output of opreport, especially when it comes to symbols in glibc,
uses internal aliases for the symbols in the output.  This is pretty
irritating to somebody who does not know what this means.  The names
can be chosen in a cleverer way to avoid this confusion.

Version-Release number of selected component (if applicable):
oprofile-0.8-20040511.12

How reproducible:
always

Steps to Reproduce:
1.oprof_start, record, and stop
2.opreport --symbols
3.
  
Actual results:
Something like
1         0.0422  0              0  2         0.1063  libc-2.3.3.so  
         __GI_getenv
1         0.0422  0              0  0              0  libc-2.3.3.so  
         __GI_getpid
1         0.0422  0              0  0              0  libc-2.3.3.so  
         __GI_strchr


Expected results:
1         0.0422  0              0  2         0.1063  libc-2.3.3.so  
         getenv
1         0.0422  0              0  0              0  libc-2.3.3.so  
         getpid
1         0.0422  0              0  0              0  libc-2.3.3.so  
         strchr



Additional info:

While correct, the __GI_* names are not the preferred names.  There
are various aliases which are better suited.  In sprof, I'm using the
following code:

          /* The function is already defined.  See whether we have
             a better name here.  */
          if (((*existp)->hidden && !newsym->hidden)
              || ((*existp)->name[0] == '_' && newsym->name[0] != '_')
              || ((*existp)->name[0] != '_' && newsym->name[0] != '_'
                  && ((*existp)->weak && !newsym->weak)))
            *existp = newsym;


I.e., the rules are: if symbol A is already found for a given address
and a second symbol B with the same address is located:

1. if A is hidden and B is not hidden, chose B

2. if first char of A is _ and the first char of B is not _, chose B

3. if both names don't start with _ and A is a weak symbol while B is
   not, chose B

4. stay with A


This all might apply to some other oprofile tools as well.
Comment 1 William Cohen 2004-09-09 16:40:35 EDT
I can see what you are talking about. As a example from an x86_64 glibc

$ nm /lib64/tls/libc-2.3.3.so|grep strcpy
0000003b1326ea60 t __GI_strcpy
0000003b1326ea60 T strcpy
0000003b13273ac0 T __strcpy_small
Comment 4 William Cohen 2004-09-17 13:33:08 EDT
Created attachment 103957 [details]
patch to select more appropriate symbol name

A first pass at selecting a more appropriate symbol name from the multiple
choices available in a shared library.
Comment 5 William Cohen 2004-09-17 13:33:59 EDT
This patch should apply cleanly to to the OProfile 0.8.1 sources.
Comment 6 Ulrich Drepper 2004-09-18 17:50:15 EDT
Yes, that patch seems to work beautifully.  Please apply.
Comment 7 William Cohen 2004-09-22 14:18:34 EDT
I submitted the patch upstream and revised it based on the comments.
The patch is checked into the upstream oprofile. The same patch has
been applied to the 0.8.1 code in the current Red Hat RPM.

Note You need to log in before you can comment on or make changes to this bug.