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.
At the same time, __stp_relocate() needs to learn how to search the same table for actual relocation base information for userspace binaries.
Basics are in since: commit c45319065d6e3ae91ae833f7afbf0edba6c87d89 Author: Mark Wielaard <mjw@redhat.com> Date: Tue Apr 21 17:16:51 2009 +0200 Add ubacktrace(), print_ustack() and print_ubacktrace(). * runtime/sym.c (_stp_usymbol_print): New function. * tapset/ucontext-unwind.stp (print_ubacktrace): New tapset function. (ubacktrace): Likewise. * tapset/ucontext-symbols.stp (print_ustack): Likewise. * testsuite/buildok/ustack.stp: New test for above three functions. There is one item left to do for this bug. sym.c (_stp_mod_sec_lookup) contains an XXX to track per task instead per _stp_section address field. This needs a small rewrite of some sym.c helper functions.
working ok so far