[Bug runtime/11573] New: uprobe_get_pc, sayonara

[Bug runtime/11573] New: uprobe_get_pc, sayonara

[fche at redhat dot com]

A systemtap script that uses ubacktrace()-related functions will end
up making a linking reference to the uprobe_get_pc() function.  But
if the script does not contain any uprobes, staprun does not load
uprobes.ko so that this reference can be satisfied, and we end up
with silly stuff like:

# rmmod uprobes
# stap -e 'probe begin {print_ubacktrace()}'
WARNING: "uprobe_get_pc"
[/tmp/stapOL691o/stap_c35e2bc620f14ccdee99bf8fb34d2ffd_1192.ko] undefined!
Error inserting module
'/tmp/stapOL691o/stap_c35e2bc620f14ccdee99bf8fb34d2ffd_1192.ko': Unknown symbol
in module
Retrying, after attempted removal of module
stap_c35e2bc620f14ccdee99bf8fb34d2ffd_1192 (rc -1)
Error inserting module
'/tmp/stapOL691o/stap_c35e2bc620f14ccdee99bf8fb34d2ffd_1192.ko': Unknown symbol
in module
Pass 5: run failed.  Try again with another '--vp 00001' option.

Possible solutions:
1) kill our reliance on uprobe_get_pc()
2) find a way of informing the translator & staprun that ubacktrace() should
   be treated as if a uprobe-y probe was requested - i.e., compile and load
   uprobes.ko
3) provide a weak definition of uprobe_get_pc()

-- 
           Summary: uprobe_get_pc, sayonara
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


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

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

[Bug runtime/11573] uprobe_get_pc, sayonara

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2010-05-06 00:13 -------
AFAICT uprobe_get_pc exists purely to hide the uretprobes perturbations to
userland PCs.  So if uprobes is not around, there is nothing to be done.
Hence, 3) makes sense and 1) would regress in the presence of uprobes.
The translator should know when emitting the module C code whether it uses
uprobes or not, no?  So it could emit a macro for the runtime headers to see,
rather than literally using a weak symbol definition of the function (which is
bloaty).

OTOH, uprobe_get_pc is something you want every PC-sampling thing to do if there
are any uprobes in use on the system, no?  So if you load a non-uprobes-using
stap script first, then later another stap run uses uprobes, the first script's
ubacktrace()s of processes uprobed by the second script could have uprobe-bogon
PCs in their traces.  Hence, you really want uprobe_get_pc to kick in whenever
uprobes is in fact loaded, even after the fact.

The .ko symbol reloc won't do that for you, i.e. change it later on uprobes
loading.  So to do it dynamic would require e.g. a fn ptr and dynamically
switching it from a stub to uprobes.ko's defn based on a module-loading notifier
seeing uprobes arrive.  That is hairy enough to make 2) attractive, certainly
for the short term.

-- 


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

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

[Bug runtime/11573] uprobe_get_pc, sayonara

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-05-06 00:23 -------
*** Bug 11433 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jistone at redhat dot com


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

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

[Bug runtime/11573] uprobe_get_pc, sayonara

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-05-07 16:59 -------
commit 6a80494

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

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