fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
sapatel has quit [Ping timeout: 256 seconds]
sapatel has joined #systemtap
sapatel has quit [Quit: Leaving]
yogananth has joined #systemtap
khaled has joined #systemtap
_whitelogger has joined #systemtap
orivej has quit [Ping timeout: 264 seconds]
drsmith has left #systemtap [#systemtap]
sapatel has joined #systemtap
drsmith has joined #systemtap
tromey has joined #systemtap
amerey has joined #systemtap
sscox has quit [Ping timeout: 260 seconds]
Amy1 has joined #systemtap
<Amy1>
how to run multiple stp scripts at the same time?
<Amy1>
every script has some probe
<fche>
that's not a problem, run multiple copies of stap
<Amy1>
so how to do?
<serhei>
could use multiple terminal windows, or a screen/tmux session
<Amy1>
This way is not cool
<Amy1>
because some program run little time.
<serhei>
that's more interesting. You could run the script continuously and have it attach to any instance of the program you start up
<Amy1>
I want some thing like stap x1.stp x2.stp "parameter" -c a.bin
<Amy1>
It's behavior like the stps is in one stp
sscox has joined #systemtap
<fche>
interesting ..... do the two stap scripts have any conflicting global variables?
<Amy1>
no
<fche>
if not, you could literally concatenate them and let one stap job run them both
<fche>
(there is no problem with a probe point being probed multiple times)
<Amy1>
do you mean I copy x1.stp and x2.stp into x3.stp ,then "stap x3.stap -c a.out"
<fche>
yes
<Amy1>
It's not cool.
<fche>
and actually
<fche>
stap FILE1.stp -E FILE2.stp also works
<fche>
sorry -E takes a script fragment not a file name
<fche>
cat FILE1.stp FILE2.stp | stap - -c a.out
<serhei>
or stap file1.stp -E "`cat file2.stp`" -c a.out
<Amy1>
how to pass parameter?
<serhei>
to the program, or to the stap script?
<Amy1>
to x1.stp and x2.stap defined using @1
<fche>
those would be conflicting globals
<fche>
well, if they conflict
<fche>
if they interpret @1 identically, then pass it as usual
<Amy1>
no conflict exist
<fche>
ok then pass it as usual, @1 will expand to the same string in both script parts
<Amy1>
serhei: your way works.
<Amy1>
if x1.stp and x2.stp have different input parameters, how to do?
<fche>
then this won't work
<fche>
given how stap -c PROGRAM is implemented, it really has to be tied to a single stap script
<fche>
so if you construct it out of multiple pieces, they have to agree internally on globals / parameters
<Amy1>
fche: do you mean that when using stap file1.stp -E "`cat file2.stp`" -c a.out, must input the same parametes?
<fche>
there is only one set of parameters
<fche>
the two scripts would have to agree how to interpret them.
<fche>
same way as there is only one set of globals
<fche>
(modulo 'private' declarations in tapsets, but never mind those)
<Amy1>
if file1.stp and file2.stap have the same name global varibles, an conflict will occur?
<fche>
likely
<fche>
again you could run the two stap scripts completely separately
<fche>
the reason you would want to combine them a bit is so that a single -c a.out invocation can be targeted
<fche>
but if your stap scripts probe all process("./a.out")'s, they'll both run independently of one another and target the same a.out
<fche>
you'd just have to launch like this:
<fche>
stap foo1.stp &
<fche>
stap foo2.stp &
<fche>
./a.out
<fche>
so you lose the synchronization between stap being ready and ./a.out being launched
<Amy1>
if open a window and run stap file1.stp and open another window and run stap file2.stp, then if file1.stp and file2.stp have a same name variable, an conflict will also not occur?
<fche>
but if you can manage that yourself somehow, then this works, and then foo1 and foo2 don't have to be aware of each other at all
<fche>
no conflict between separate runs of stap
<Amy1>
cool
<Amy1>
I think stap should add a new usage that stap -filelist x1.stap x2.stap parameter1 parameter2 -c ./a.out
<fche>
yeah but in your case, you said they may disagree on parameters
<Amy1>
Then something will be convinient.
<fche>
as far as supporting multiple stp scripts, deconflicting globals .... that's something we could probably do
<Amy1>
cool
<Amy1>
open multi window is not cool
sscox has quit [Ping timeout: 250 seconds]
<fche>
well, you don't need multiple windows to launch a few copies of stap ; background & ops, output redirection etc. all work
<Amy1>
I dont' want to open multi windows and -E is weak. If using the way I proposed, then I can write multi stap command in one shell, and control them.
<Amy1>
quickly
sscox has joined #systemtap
<Amy1>
I want to combine multi stp scripts and fast switch between these combinations.
<Amy1>
So cool is it, isn't it?
<fche>
ok. I'm just not sure how smoothly that can integrate into the command line parsing logic we have.
<fche>
it's not just a couple lines of code we're talking about
<Amy1>
I think if there is no conflict, it is easy to code.
<fche>
naturally, code has to deal with conflicts :)
<Amy1>
If found confict, you can break down and exit compile in the first version
<Amy1>
and it should break down originally
<Amy1>
If has conflict, it is an error like c++ namespace conflict.
<Amy1>
Breaking down the compile is right.
<Amy1>
So the difficult problem is to parse stap arguments now.