Bug 131417
| Summary: | opreport does not use preferred symbol names | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ulrich Drepper <drepper> | ||||
| Component: | oprofile | Assignee: | William Cohen <wcohen> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 0.8.1-8 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2004-09-22 18:18:34 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 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.
This patch should apply cleanly to to the OProfile 0.8.1 sources. Yes, that patch seems to work beautifully. Please apply. 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. |
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.