Description of problem: tprobe.c: #include <sys/sdt.h> main() { DTRACE_PROBE2(test, main, 1, 2); } gcc -g -o tprobe tprobe.c tprobe.stp: probe process("tprobe").mark("test") { println($arg1) println($arg2) } $ sudo stap tprobe.stp semantic error: while resolving probe point: identifier 'process' at tprobe.stp:2:7 source: probe process("tprobe").mark("test") { ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] Version-Release number of selected component (if applicable): systemtap-2.3-1.fc19.x86_64 kernel 3.10.10-200.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. see above 2. 3. Actual results: See above Expected results: Parse the file, probe the probe. Additional info:
Hi, Andi. This just works for me on f19, with same stap version, but a somewhat earlier kernel (3.10.5). Can you try ... % readelf -n tprobe % stap --vp 03 -L 'process("tprobe").mark("*")'
I think actual error here is that the .mark parameter should be .mark("main"). The 'test' parameter is what's referred to as the provider. More information can be found at https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps an alternative probe point could also be process("tprobe").provider("test").mark("main"){...}
Good eyes, Lukas.
Ok I tracked it down. It seems to be related to stap not seeing the binary (plus the typo) Perhaps the documentation should be clearer on this. For example if I specify an absolute path, does it always match the same binary even when called non absolute? I presume it does because it's matching on the inode.
The stapprobes man page includes this: > Note that for all process probes, PATH names refer to executables > that are searched the same way shells do: relative to the working > directory if they contain a "/" character, otherwise in $PATH. > [...] The runtime will indeed match things absolutely, not just by inode but via elf build-ids.