When probing by pid using the "probe process(<pid>)" syntax and not having -x or -c specified, --runtime=dyninst mode complains about missing -x or -c switch and does not actually work: -------------------------------8<------------------------------------ 7.0 S x86_64 # cat test.c void nop() {}; int main() { while(!sleep(1)) nop(); return(0); } 7.0 S x86_64 # gcc -g test.c 7.0 S x86_64 # ./a.out & [3] 22364 7.0 S x86_64 # stap -ve 'probe process(22364).function("nop") {log("hit")}' Pass 1: parsed user script and 113 library script(s) using 218008virt/35320res/3048shr/32732data kb, in 160usr/10sys/164real ms. Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 218800virt/36688res/3680shr/33524data kb, in 0usr/0sys/5real ms. Pass 3: translated to C into "/tmp/stapKiiPjT/stap_f9cb621ebc98e2e2c85401cabfef45cc_1093_src.c" using 219064virt/37288res/4072shr/33788data kb, in 10usr/40sys/57real ms. Pass 4: compiled C into "stap_f9cb621ebc98e2e2c85401cabfef45cc_1093.ko" in 1860usr/250sys/2124real ms. Pass 5: starting run. hit hit hit ^CPass 5: run completed in 20usr/60sys/3249real ms. 7.0 S x86_64 # stap --runtime=dyninst -ve 'probe process(22364).function("nop") {log("hit")}' Pass 1: parsed user script and 46 library script(s) using 191168virt/9052res/3024shr/5892data kb, in 30usr/0sys/33real ms. Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 191432virt/9928res/3668shr/6156data kb, in 0usr/0sys/1real ms. Pass 3: translated to C into "/tmp/stapYU8fAJ/stap_44550b941b2325a0d3f7b68946033d80_1095_src.c" using 191696virt/10528res/4064shr/6420data kb, in 10usr/50sys/62real ms. Pass 4: compiled C into "stap_44550b941b2325a0d3f7b68946033d80_1095.so" in 600usr/20sys/633real ms. Pass 5: starting run. stapdyn: WARNING: process probes require a target (-c or -x) ^CPass 5: run completed in 0usr/10sys/14324real ms. 7.0 S x86_64 # -------------------------------8<------------------------------------ This actually breaks the process_by_pid.stp testcase on el7 and f20.
Right, the dyninst mode is not system-wide like the kernel -- we have to explicitly attach to processes. Right now we choose to simply attach to the -x/-c process and any children we see forked after that. I suppose we could attempt additional attachments based on the process(PID) probes in the script. However, I think we may have other issues internally in the way the PID is encoded, overloading the offset field. That works fine for process(PID).begin/end, but we'll need a true offset for .function to work. It looks like the call to dynprobe_add_uprobe() is currently ignoring any PID. (These process(PID) uprobe types are new in 2.6, so they weren't a consideration when this stapdyn code was written.)
This is inherent in forseeable dyninst capabilities and absence of something like a dyninst systemwide process server thingie.