This is the mail archive of the 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 translator/3849] Delay assigning command-line parameters until runtime

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


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