14:08 <Jack_> Hi everyone, can someone confirm that process().function().return does not work with systemtap and dyninst (stap --dyninst)?

14:18 <fche> ISTR it should work

14:21 <Jack_> Huh, I'm using systemtap 3.1 with dyninst 9.3.0 (both built from sources)

14:30 <Jack_> I just wrote a minimal working example to showcase the issue, but in the MWE it works...

14:36 <fche> "MWE" ?

14:36 <fche> urbandictionary is leading me astray with that acronym

14:37 <fche> oh minimal working example, hahahaha got it

14:41 <Jack_> MWE = minimal working example

14:41 <Jack_> :D

14:41 <Jack_> But it still isn't working in my application.

14:49 <fche> hm I have dyninst 9.2 on my box here, and it's way less capable than the lkm backend for process probing :(

14:57 <Jack_> Frank, could you please have a look at this example? http://pastebin.com/WyLEV00a

14:57 <fche> looks like it should work

14:58 <fche> though dyninst does like debuginfo some - add CFLAGS=-g for a spicier taste

15:07 <Jack_> -g did not help, but for some reason this MWE works: http://pastebin.com/33wibYrJ (with the exact same stap script!)

15:08 <fche> bummer

15:08 <fche> jistone might be around in a few hours, he has some dyninst internals experience

15:09 <fche> I wonder if we may need any more stap widgetry to make diagnosing such problems (possible dyninst bugs) easier

15:09 <fche> at the least, if you use stap -k .... you'll get a look at the dyninst api client source code

15:11 <Jack_> Ok, thanks for the info.

15:11 <Jack_> stapdyn: found target "[...]/simple" in pid 15510, inserting 2 probes

15:13 <fche> ah right, and stap --vp 00005 or such, to pass more verbosity to stapdyn

15:15 <Jack_> Reading the source of /tmp/stapXXX/stap_XXX_src.c, the two probe points are definitely there.

15:15 <fche> yeah, and I'd imagine the same in the previous non-working case

15:24 <Jack_> Can you maybe spot any significant difference in the logs? https://paste.debian.net/hidden/0808080d/

15:27 <fche> well, the missing "Leaving function factor" bit :-(

15:29 <fche> in the stap --vp ... command line, do you see the execution command line for stapdyn?

15:29 <fche> how many -v's made it in there?

15:30 <fche> I guess there ought to be four, so staplog(4) or lesser messages from stapdyn/*.cxx ought to get printed

15:30 <fche> I guess we could use a lot more such diagnostics in the code

15:32 <Jack_> I ran with 'stap --dyninst --vp 00005' which resulted in 'stapdyn -v -v -v -v' (i.e. four v's)

15:32 <fche> ok yeah

15:33 <fche> would you mind opening a bug report in sourceware.org/bugzilla ? or shall I?

15:33 <fche> not sure how much/soon time we can have to figure this out

15:33 <Jack_> Does stapdyn even support more than one '-v'? https://sourceware.org/systemtap/man/stapdyn.8.html

15:33 <fche> yeah, stapdyn.cxx:90

15:34 <Jack_> I'll file a bug report.

15:34 <fche> thanks

15:34 <fche> sorry :)

15:34 <Jack_> No, thank you for your help :-)

22:25 <irker670> systemtap: dsmith systemtap.git:refs/heads/master * release-3.1-12-g701bb5d / scripts/dump-syscalls.sh tapset/linux/arm/syscall_num.stp tapset/linux/arm64/syscall_num.stp tapset/linux/i386/syscall_num.stp tapset/linux/mips/syscall_num.stp tapset/linux/powerpc/syscall_num.stp tapset/linux/x86_64/syscall_num.stp: Regenerated tapset/linux/ARCH/syscall_num.stp files. http://tinyurl.com/zcftu6y

22:31 <irker670> systemtap: dsmith systemtap.git:refs/heads/master * release-3.1-13-g13d1fc0 / testsuite/systemtap.syscall/getrandom.c testsuite/systemtap.syscall/kexec_load.c testsuite/systemtap.syscall/tapset/syscall.stp: Improve syscall test case results on newer powerpc kernels. http://tinyurl.com/j3bt4hs