Bug 10917 - environment variable expansion in executable search
Summary: environment variable expansion in executable search
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-08 02:07 UTC by James Y Knight
Modified: 2011-05-16 14:36 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Y Knight 2009-11-08 02:07:16 UTC
I'd like to be able to do:
probe process("$INSTALL/lib/libMyStuff.so").function("hello") {}

That is: in addition to doing $PATH finding for the process probe, I'd like it to first expand environment 
variables from the user (the one running stap)'s environment.

At first thought, I'd have $$ to escape a $, and also support "${ENVVARNAME}".

If you think this is a good idea, I should be able to come up with a patch to implement it.
Comment 1 Frank Ch. Eigler 2009-11-09 16:42:01 UTC
Can you look at bug #10485, and see if that would be another way of solving your
problem?  The gist would be to install your tapset script under a subdirectory
name that encodes your $INSTALL directory.
Comment 2 James Y Knight 2009-11-09 17:33:39 UTC
I don't think that would work for me. I want this for development-use, so installing stuff into system 
directories is not really appropriate. The install directory for the source tree I'm working on (and I may be 
working on multiple) is selected via the env var $APPINSTALL (and $PATH is updated automatically as well 
via a shell function).

So, if I check in a stp script to the source tree, I want it to find the libs for my *current* install, which is 
determined by $APPINSTALL. I don't want to have to install the stp script into a special system location in 
order for it to work -- I should be able to edit and use it directly from the source tree, ideally.
Comment 3 Frank Ch. Eigler 2009-11-24 16:44:43 UTC
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.
Comment 4 James Y Knight 2009-11-24 17:14:56 UTC
Thanks for the response. 

Bug 6880 indeed looks like a reasonable solution to my problem: if a "library" probe searched 
LD_LIBRARY_PATH for the library, that'd work well for me in this situation, and if process(...).library(...) 
found the library no matter what way that process loaded it, that'd be useful for many other situations.

I also think generic (usable anywhere) parse-time env var expansion suppport would be quite nice too. 
Your proposal #4 is certainly a *much* better idea than my proposal of just doing it in this one special 
case.
Comment 5 Stan Cox 2011-05-16 14:36:38 UTC
6880 is now implemented