This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/3849] Delay assigning command-line parameters until runtime
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 23 Jan 2007 15:15:32 -0000
- Subject: [Bug translator/3849] Delay assigning command-line parameters until runtime
- References: <20070110011521.3849.joshua.i.stone@intel.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From fche at redhat dot com 2007-01-23 15:15 -------
(In reply to comment #2)
> Right -- that's why I said "Some analysis may be needed". For parameters that
> are used in probe points we should expand them right away. For parameters that
> are only used as literals in the probe bodies, we can delay assignment until
> runtime.
Would this not be confusing to the user? Would you signal an error if a
@1/$1 was used in a compile-time context (probe points) once, then the user
tried to rerun the script with different parameters? Or just slow it down
(by disabling the cache)? What if in the future, the translator does more
optimizations with probe handlers (constant propagation of $1/@1 variables),
which would make those similarly uncacheable?
> > We already support a run-time parametrization method to some extent:
> > initializing global variables by name, [...]
>
> Well, there's no way to pass in module parameters through stap.
That is just a SMOP and should be added there for passing through to staprun.
What you propose is probably implementable, but it may be too complicated
to do and to explain.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3849
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.