Bug 564429 - Errors parsing .probes section in the presence of prelink
Errors parsing .probes section in the presence of prelink
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: systemtap (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Mark Wielaard
Fedora Extras Quality Assurance
:
Depends On: 563528
Blocks: StapStaticProbesF13
  Show dependency treegraph
 
Reported: 2010-02-12 12:45 EST by Dave Malcolm
Modified: 2010-02-19 04:21 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 564445 (view as bug list)
Environment:
Last Closed: 2010-02-19 04:21:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log from invocation of systemtap (4.76 KB, text/plain)
2010-02-12 12:46 EST, Dave Malcolm
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 11173 None None None Never

  None (edit)
Description Dave Malcolm 2010-02-12 12:45:12 EST
Description of problem:
As discussed on IRC today, systemtap can sometimes fail to parse static markers in a library due to prelink.

Apparently this is fixed in git; I'm filing this bug and adding it to the F13 tracker bug to ensure that this fix makes it into F13.


Version-Release number of selected component (if applicable):
systemtap-1.1-1.fc13.i686

How reproducible:
Sometimes

Steps to Reproduce:
1. Prelink a library containing static markers:
  # prelink /usr/lib/libpython2.6.so.1.0
2. Try to use those markers:
  # stap -vvvvv --vp 01 /usr/share/doc/python-libs-2.6.4/systemtap-example.stp

 
Actual results:
semantic error: no match while resolving probe point process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__entry")
semantic error: no match while resolving probe point python.function.entry


Expected results:
Probepoint should work

Additional info:
Undoing prelink makes it work again:

# prelink -u /usr/lib/libpython2.6.so.1.0
# stap /usr/share/doc/python-libs-2.6.4/systemtap-example.stp -c yum help
     0 yum(25931): => <module> in /usr/lib/python2.6/site.py:59
   444 yum(25931):  => <module> in /usr/lib/python2.6/os.py:22
  1043 yum(25931):   => <module> in /usr/lib/python2.6/posixpath.py:11
  1155 yum(25931):    => <module> in /usr/lib/python2.6/stat.py:4
  1172 yum(25931):    <= <module> in /usr/lib/python2.6/stat.py:94
  1279 yum(25931):    => <module> in /usr/lib/python2.6/genericpath.py:5
  1298 yum(25931):    <= <module> in /usr/lib/python2.6/genericpath.py:85
  1492 yum(25931):    => <module> in /usr/lib/python2.6/warnings.py:1
  1688 yum(25931):     => <module> in /usr/lib/python2.6/linecache.py:6
  1707 yum(25931):     <= <module> in /usr/lib/python2.6/linecache.py:68
(snip)

I'm about to attach the more detailed error log from the failure.
Comment 1 Dave Malcolm 2010-02-12 12:46:14 EST
Created attachment 390545 [details]
Log from invocation of systemtap
Comment 2 Dave Malcolm 2010-02-12 12:47:01 EST
# eu-readelf -x .probes /usr/lib/libpython2.6.so.1.0 

Hex dump of section [24] '.probes', 84 bytes at offset 0x186940:
  0x00000000 66756e63 74696f6e 5f5f656e 74727900 function__entry.
  0x00000010 50524231 00000000 40691800 00000000 PRB1....@i......
  0x00000020 660a0c00 00000000 66756e63 74696f6e f.......function
  0x00000030 5f5f7265 7475726e 00000000 50524231 __return....PRB1
  0x00000040 68691800 00000000 6e100c00 00000000 hi......n.......
  0x00000050 00000000
Comment 3 Mark Wielaard 2010-02-12 13:55:56 EST
This is upsteam bug "Markers get a bad address in prelinked libraries"
http://sourceware.org/bugzilla/show_bug.cgi?id=11173
Fix is already in upstream git, but just missed the 1.1 release

If we don't make a new systemtap release then in addition of the above patch we will also need commit 87748e.

commit 08d1d520616557f6ff7dd023e260ad6577e9e0e8
Author: Mark Wielaard <mjw@redhat.com>
Date:   Mon Jan 18 09:13:30 2010 +0100

    PR11173 Markers get a bad address in prelinked libraries.
    
    Our literal_addr_to_sym_addr() function was just wrong. To compensate for
    raw addresses read from elf (either given by the user or through a mark
    transformation) we need to know what the elf_bias is (as returned by
    dwfl_module_getelf) before feeding them to any libdwfl functions.
    
    * tapsets.cxx (query_module_dwarf): Always add elf_bias to raw function or
      statement addresses before calling query_addr().
      (query_addr): Don't call literal_addr_to_sym_addr().
    * dwflpp.h (literal_addr_to_sym_addr): Removed.
    * dwflpp.cxx (literal_addr_to_sym_addr): Likewise.

commit 87748e2b87e574d3c83866ccd0d83678c3c68d93
Author: Mark Wielaard <mjw@redhat.com>
Date:   Tue Feb 2 13:47:19 2010 +0100

    Make sure cfa_ops are always retrieved through dwfl global address.
    
    dwflpp::translate_location() works on the dw address space, but
    get_cfa_ops() starts out with dwfl calls (only dwarf_cfi_addrframe()
    needs to be adjusted for bias).
    
    * dwflpp.cxx (translate_location): Pass pc plus module bias through to
      get_cfa_ops.
      (get_cfa_ops): Adjust for bias when calling dwarf_cfi_addrframe(),
      add frame start/end address when found if verbose logging.
    * testsuite/systemtap.exelib/lib.stp: Add $foo and $bar variables to
      process.function probes.
    * testsuite/systemtap.exelib/libmarkunamestack.stp: Likewise.
    * testsuite/systemtap.exelib/lib.tcl: Expect correct values for
      process.function probe variables.
    * testsuite/systemtap.exelib/libmarkunamestack.tcl: Likewise.

That last patch relies on an elfutils fix: https://bugzilla.redhat.com/show_bug.cgi?id=546295
Comment 4 Mark Wielaard 2010-02-19 04:21:00 EST
systemtap-1.1-2.fc13 and systemtap-1.1-2.fc12 have been pushed with the patches
from comment #3. Which should fix this issue mostly. Full fix will be when new
elfutils 0.145 lands (any day now).

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