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/11573] uprobe_get_pc, sayonara


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


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