While probing a function like : void timer_stats_update_stats(void *timer, pid_t pid, void *startf, void *timerf, char *comm, unsigned int timer_flag) one can determine only address of timer interrupt handler (timerf). One needs to lookup /proc/kallsyms to lookup what handler-function name this address corresponds to. It'll proly be a good idea for systemtap translator/tapsets to have functions for this.
As a part of bug #6580, symname() has already been added to the tapset.
Subject: Re: Enable stap to map function addresses to function names fche at redhat dot com wrote: > ------- Additional Comments From fche at redhat dot com 2009-05-20 11:33 ------- > As a part of bug #6580, symname() has already been added to the tapset. > > > Thanks Frank !! This construct doesnt seem to work in dwarfless scenario (in probe kprobe.function{} context). Any pointers on what could be done to get it working ?
(In reply to comment #2) > Thanks Frank !! This construct doesnt seem to work in dwarfless scenario > (in probe kprobe.function{} context). > Any pointers on what could be done to get it working ? You need to add dwarf :) stap -d kernel (or stap -d module-name) will make the symbols available by reading them from the debuginfo.
> > Thanks Frank !! This construct doesnt seem to work in dwarfless scenario > > You need to add dwarf :) > stap -d kernel (or stap -d module-name) will make the symbols available by > reading them from the debuginfo. Yeah, but that seems to defeat the purpose of dwarfless probing. Maybe extend -d to accept a (presumed) kernel symbol table file -d /lib/modules/`uname -r`/build/System.map And the kprobes.* logic can add this to session.unwindsyms. For that matter, it could read the file (like in jkenisto's older symbol-table-based probing implementation) to verify placement of kernel-side symbol probes.
With fedora-like distros, where gdb minidebuginfo symbol tables are present in the executable, this sort of extra effort is not needed. systemtap/elfutils can pull symbols out of there for usymname() resolution purposes. https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html but see also https://bugzilla.redhat.com/show_bug.cgi?id=1714804