08:28 <irker629> systemtap: mcermak systemtap.git:refs/heads/master * release-3.1-36-g4ae155a / tapset/linux/aux_syscalls.stp tapset/linux/i386/syscall_num.stp tapset/linux/sysc_statx.stp tapset/linux/x86_64/syscall_num.stp testsuite/buildok/nd_syscalls2-detailed.stp testsuite/buildok/syscalls2-detailed.stp testsuite/systemtap.syscall/stat.c: PR21297 Add support for new statx syscall http://tinyurl.com/lhoterb

12:12 <efiop> Hi! I want to dereference a single pointer in systemtap to print it, but I don't quite get how. I.e. if i had a probe on a fucntion with argument foo, that is a pointer to a struct with member bar, then I would print it as "%d\n", $foo->bar. But what if foo is a pointer to, lets say, int, how do I print *foo in systemtap?

12:12 <fche> user_int($addr) or kernel_int($addr)

12:12 <fche> we should get a dereference operator before too long though

12:13 <efiop> It works! Thanks!

12:14 <efiop> Not very intuitive, though =) Did quite a bit of googling and greping through the manual, but didn't manage to find an answer.

12:14 <fche> sorry about that :)

12:14 <fche> if you'd be willing to draft up a sentence or two diffs to the man page, I'd love to merge it

12:17 <efiop> Sure, will be more than happy! I'm just going through the HACKING doc and setting up my env.

12:18 <fche> I guess the man/.../stapprobes.3stap is the page where $var->field is explained most

12:34 <efiop> Aha! stapprobes.3stap +727: $addr[0] {kernel,user}_{char,int,...}(& $addr[0]) .

12:40 <fche> or just $addr

12:41 <fche> oh I see what you're quoting

12:41 <fche> that was just an explanation on .return probes

12:42 <efiop> Yeah, just found a kernel_int() mentioning inthere.

12:42 <fche> I'd put the new mention higher up, where $var->field traversal, $return etc are first mentioned, more like 43% the way in

12:43 <efiop> After a bit for surfing through the man pages, I actually think the best way to put a note on dereferencing pointer itself is in https://sourceware.org/systemtap/man/stap.1.html TYPECASTING

12:43 <efiop> as this is probably the first place where people will find dereferencing of the members and thus might find a note about dereferencing pointer itself.

12:44 <efiop> What do you think?

12:51 <fche> you're probably right; we should mention these -> etc. bits there too.

13:07 <efiop> Sent a patch https://sourceware.org/ml/systemtap/2017-q2/msg00006.html

13:14 <fche> looks good, thanks!

13:15 <irker661> systemtap: rkuprieiev systemtap.git:refs/heads/master * release-3.1-37-g39b70de / man/stap.1.in man/stapprobes.3stap: man: add a note about direct pointer dereferencing http://tinyurl.com/k999s6u

13:41 <efiop> Thanks for your help!

13:47 <fche> thanks!

16:43 <georgj> Hello!

16:43 <georgj> I think I found a small bug in the default tapset.

16:44 <georgj> When I use the syscall.fnctl probe, there is the possibility of triggering it twice

16:47 <georgj> probe syscall.fcntl {

16:47 <georgj> }

16:47 <georgj> probe syscall.fcntl.return {

16:47 <georgj> }

16:47 <georgj> printf("\nSYSCALL %s\n", probefunc())

16:47 <georgj> if (pid() == target()) {

16:47 <georgj> if (pid() == target()) {

16:47 <georgj> printf("\nRETURN\n")

16:47 <georgj> }

16:47 <georgj> }

16:47 <georgj> With this script: https://pastebin.com/C94wCs2a, I get the following output:

16:48 <georgj> SYSCALL compat_sys_fcntl64

16:48 <georgj> SYSCALL SyS_fcntl

16:48 <georgj> RETURN

16:48 <georgj> RETURN

16:49 <georgj> test app:

16:50 <georgj> https://thepasteb.in/p/WnhzOV7rrOPcV

16:51 <georgj> this probably happens because the probe gets installed at multiple locations instead of only the first available one: https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=blob;f=tapset/linux/sysc_fcntl.stp;h=9747ea29eb83edc8f82d30d7a02ff0c5d9fc93b0;hb=4ae155ae612963b95d9a9a05273ab4baade1cf83#l23

16:51 <georgj> but I'm not sure how to fix this because I don't know enough about kernel internals

16:52 <georgj> (I don't know in what order the hooking functions should be specified)

16:53 <fche> hm interesting question . and maybe with different answers for 32- vs 64-bit application

16:57 <georgj> that's true

16:58 <georgj> my computer is 64 bit but the bug only triggers if the app is 32bit

16:58 <fche> if your app is 64bit, is only the latter or only the former triggered?

16:59 <georgj> i'll test

17:00 <georgj> SYSCALL SyS_fcntl

17:00 <georgj> RETURN

17:02 <fche> ok. what's happening here is that the compat_* call takes the 32-bit syscall args, jams them into 64-bit places, then calls the 64-bit syscall handler to do the work

17:02 <fche> more or less

17:02 <georgj> I agree

17:03 <georgj> I was wondering if it's even necessary to hook the compat_ calls or if they always call the real function

17:03 <fche> drsmith might know

17:04 <drsmith> I think the answer to that question is "it depends"

17:04 <drsmith> it is probably half and half

17:05 <drsmith> we take pains in the syscall/nd_syscall tapsets to make sure you only get 1 probe hit even the the compat call ends up calling the real call

17:05 <drsmith> s/even the/even when the/

17:06 <fche> where is that mechanism visible?

17:06 <drsmith> if fcntl is doing this to you, its a bug

17:06 <georgj> @fche, most syscalls use aliases with ! instead of ?

17:08 <drsmith> the fix would be to add a call to @__syscall_gate_compat_simple (or one of its variants) to the "real" call

17:08 <georgj> @fche: i might actually be mistaken, I can't find any instance of that right now

17:08 <drsmith> what kernel/arch are you on?

17:08 <fche> georgj, there are different levels of aliases

17:08 <georgj> Linux ubuntu 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

17:09 <drsmith> what version of systemtap?

17:09 <georgj> Systemtap translator/driver (version 3.1/0.158, non-git sources)

17:10 <drsmith> I wonder why the testsuite hasn't seen this

17:14 <drsmith> hmm, when running the testsuite's example program by hand, I do see this problem

17:20 <drsmith> georgj: thanks for the bug report, I'll file a pr and get this fixed today or tomorrow

17:21 <georgj> thank you both for the quick response! that's just amazing :-)

17:21 <fche> hey thanks for dropping by and giving the tool a chance

17:46 <drsmith> hmm, I think I see how this got past the testsuite logic

17:46 <drsmith> it basically skips input it doesn't understand