[Bug translator/10174] New: Enable stap to map function addresses to function names

[Bug translator/10174] New: Enable stap to map function addresses to function names

[prerna at linux dot vnet dot ibm dot com]

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.

-- 
           Summary: Enable stap to map function addresses to function names
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: prerna at linux dot vnet dot ibm dot com


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

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

[Bug translator/10174] Enable stap to map function addresses to function names

[fche at redhat dot com]

------- 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.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

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

[Bug translator/10174] Enable stap to map function addresses to function names

[prerna at linux dot vnet dot ibm dot com]

------- Additional Comments From prerna at linux dot vnet dot ibm dot com  2009-05-25 04:54 -------
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 ?



-- 


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

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

[Bug translator/10174] Enable stap to map function addresses to function names

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-05-25 07:25 -------
(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.


-- 


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

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

[Bug translator/10174] Enable stap to map function addresses to function names

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-05-25 16:24 -------
> > 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.


-- 


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

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

[Bug translator/10174] let stap -d take a symbol table file as argument, for dwarfless *symname()

[fche at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|0000-00-00 00:00:00         |2010-08-12 18:11:34
               date|                            |
            Summary|Enable stap to map function |let stap -d take a symbol
                   |addresses to function names |table file as argument, for
                   |                            |dwarfless *symname()


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

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

[Bug translator/10174] let stap -d take a symbol table file as argument, for dwarfless *symname()

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10174

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|---                         |WORKSFORME

--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> ---
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

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