[Bug translator/10917] environment variable expansion in executable search

["fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From fche at redhat dot com  2009-11-24 16:44 -------
James, in the PR10485 model, one would do this by installing a
tapset file such as
     probe mystuff.hello = process("libMyStuff.so").function("hello") {}
into
     /ANYWHERE/tapset/AUTOPATH/$INSTALL/lib/libMyStuff.so
then
     stap -I /ANYWHERE/tapset -e 'probe mystuff.hello { }'
This may be suitable for probe points that are a priori known interesting.

For ad-hoc probing, there are a few other ways:
1) build the script on the fly:   
   #! /bin/sh
   stap -e 'probe process("'$INSTALL'/lib/libMyStuff.so").function("hello") { ... }'
so a shell does the interpolation.
2) put $INSTALL/lib into your temporary PATH, so that
   stap -e 'probe process("libMyStuff.so").function("hello") { }'
would work since we search $PATH for unqualified process("..") names
3) (wait for systemtap bug #6880, which should automate searching for
shared libraries based on program binaries and $LD_LIBRARY_PATH)
4) (wait for another possible extension:   @env("name")  as a parse-time
expanded literal ... but this would also require parse-time concatenated
string literals in order to be useful as a process probe parameter:
    probe process (@env("INSTALL") "/lib/libMyStuff.so") { |


By the way the reason I'm hesitant about the original proposal
-- interpolation of values within string literals -- is because
this would be the first such scenario in systemtap.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10917

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.