16:28 <lorddoskias> is systemtap supported on s390 ?

16:29 <lorddoskias> i'm getting the following pass4 failures: http://paste.ubuntu.com/24414781/

16:34 <fche> lorddoskias, how recent is your stap?

16:34 <lorddoskias> Systemtap translator/driver (version 3.0/0.158, non-git sources)

16:35 <lorddoskias> kernel is : 4.4.59

16:36 <lorddoskias> i can also get latest git if that will solve the problem

16:36 <fche> sounds familiar

16:38 <lorddoskias> ok let me compile the latest git

16:38 <fche> or just the 3.1 release

16:38 <fche> (you'll thank me later)

16:39 <fche> (git stap is in flux from the ebpf backend merge)

16:39 <lorddoskias> 3.1 then :)

16:42 <lorddoskias> i realize how much i have forgotten from not having used stap for a while ;\

16:43 <fche> BOO

16:43 <fche> :-

16:43 <fche> )

16:49 <lorddoskias> fche: okay, it worked with the newer version

16:51 <fche> SHIP IT HARD

16:51 <fche> SHIP IT NOW

16:51 <fche> SAIL THE OPEN SEAS

16:53 <lorddoskias> heheh ;)

16:53 <lorddoskias> so with the ebpf backend you will expect to have more performance and also reduce the sitaution in which you have to compile kernel modules or am i mistaken ?

16:59 <lorddoskias> fche: when using a return probe, e.g. stap -dxfs -L 'module("xfs").function("xfs_quota_flags").return' stap shows that i also have access to the input params: module("xfs").function("xfs_quota_flags@../fs/xfs/xfs_quotaops.c:151").return $return:unsigned int $uflags:unsigned int $flags:unsigned int

16:59 <lorddoskias> however, when i use it in my script i get the following warning: WARNING: confusing usage, consider @entry($uflags) in .return probe: identifier '$uflags' at xfs.stap:9:77

16:59 <lorddoskias> WARNING: confusing usage, consider @entry($uflags) in .return probe: identifier '$uflags' at xfs.stap:9:77

16:59 <lorddoskias> source: printf("Returning from xfs_quota_flags: uflags(input) = %d return = %d\n", $uflags, $return)

18:32 <drsmith> lorddoskias: what it is complaining about is the fact that in return probes, we don't really know if you want the *current* value of $foo or the *original* value of $foo (upon entry to the function)

18:32 <drsmith> @entry($foo) specifies the latter

18:33 <drsmith> hmm, if you really want the *current* value, I'm not sure how to shut that warning up

18:38 <drsmith> ah, it looks like the value is always the original value

18:40 <fche> yeah $foo and @entry($foo) are the same in .return, but some more complex case aren't

18:55 <jistone> by the time a .return probe is actually handled, the stack frame is already gone, so you generally can't access "current" values of the original function at all

18:55 <jistone> I think there was a bug about locating pre-return probe points

18:56 <jistone> (a bug for enhancement, I mean)