[Bug translator/20394] inconsistency in exe/library paths searching between @cast() and process.library.function probes
fche at redhat dot com
sourceware-bugzilla@sourceware.org
Thu Jul 21 15:06:00 GMT 2016
https://sourceware.org/bugzilla/show_bug.cgi?id=20394
Frank Ch. Eigler <fche at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fche at redhat dot com
--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
Having a search path in @cast in a function() makes it possible that a mismatch
will exist between the probe (whose $context variable is being passed) and the
@cast (who interprets that pointer). What you seem to really want is to make
@cast() in a function refer to - match - the context of the probe that invoked
it. This is kind of what we do already for @cast()s in probe handler bodies.
It's as though we want to specialize the functions invoked from a probe handler
by the probe handler, almost as if they were inlined. Then syntactic elements
inside the functions (even $vars) could conceivably be resolved in the context
of each probe where those functions are actually called from.
What do you think?
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Systemtap
mailing list