This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/20394] inconsistency in exe/library paths searching between @cast() and process.library.function probes
- From: "dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 21 Jul 2016 15:50:24 +0000
- Subject: [Bug translator/20394] inconsistency in exe/library paths searching between @cast() and process.library.function probes
- Auto-submitted: auto-generated
- References: <bug-20394-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20394
--- Comment #2 from David Smith <dsmith at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #1)
> 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?
That's an interesting idea. If it is doable, I'd say it would be quite handy.
--
You are receiving this mail because:
You are the assignee for the bug.