This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug runtime/6866] New: Extend stp_symbol_snprintf for user space


Currently stp_symbol_snprintf (and _stp_func_print, _stp_symbol_print) in
runtime/sym.c only reliably work for kernel symbols. There is a little support
for printing (static) user space executable symbols when running stap with -d
for the executable you are interested in. But that only kind of works by accident.

An executable given through -d is currently treated in main.cxx as "just"
another kernel module which is added to the systemtap_session.unwindsym_modules
vector. translate.cxx then outputs the _stp_symbol[] for a _stp_section in the
"fake" _stp_module for the binary in the stap-symbols.h file.

All the stp_symbol functions call _stp_kallsyms_lookup() which finds the closest
section and associated module, which, if the given address happens to be in user
space, will find the address associated with a user space symbol for the
executable _stp_module entry. Note that this only really works for one
executable given, so is unreliably when multiple executables can queried in a
probe. See bug #6580 comment #1 for an example of when this (kind of) works.

To make this work reliably one has to associate the _stp_module entry
(_stp_symbol table) of the executable given with -d to the actual/current
process active during the probe. Then when calling _stp_kallsyms_lookup() one
can check whether the given address is in user space and do the lookup in the
right symbol table.

The most likely candidate for this mapping would be the _stp_tf_vma_entry struct
 so we can query __stp_tf_get_vma_entry() for the current task and requested
address to get the correct symbol table. The association would be done on
__stp_tf_add_vma when the vma is file based and matches the executable
_stp_module name field.

This assumes each such executable module has just one section with symbols.
Which I assume is correct since for executables with shared libraries we would
supply each .so separately.

-- 
           Summary: Extend stp_symbol_snprintf for user space
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6866

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]