13:31 <invano> hi all, hi fche. I built some user probes for multiple archs and I have a couple on i386 built around %xmm1. However, stap "Can't parse SDT_V3 operand '%xmm1'". Apparently there is no support for register xmm1, correct?

13:32 <fche> ah interesting

13:32 <fche> would have to find out whether the kernel-provided pt_regs (at uprobe entry) includes the xmm registers

13:32 <fche> if so, stap should be able to get at that value, yeah

13:33 <invano> mmhh cool. I need to have a look at that.

13:34 <fche> it may not be too easy -- the kernel handles floating point values Cleverly

13:34 <fche> and fwiw systemtap doesn't handle floating point values much or well; have you considered changing the sys/sdt.h marker to take integral parameters?

13:35 <irker604> systemtap: dsmith systemtap.git:refs/heads/master * release-3.1-73-g65a4cde / session.cxx: Updated the list of tested kernel versions to include 4.11. http://tinyurl.com/mxfpq7w

13:39 <invano> Actually I'm inserting probes in glibc and for i386 some asm funcs move the argument (e.g. a char *) from stack to xmm1 with a movd. I can easily solve this by rewriting the asm in some other ways. At the same time I'm curious to check how stap handle xmm1. so I'll have a look at it when I have some free time.

13:43 <fche> for this part, see sdt_uprobe_var_expanding_visitor::build_dwarf_registers in tapsets.cxx

13:44 <fche> and sdt_uprobe_var_expanding_visitor::visit_target_symbol_arg

13:45 <fche> you could pass the stack argument pointer to the sdt marker instead of the xmm register

14:18 <invano> uh thanks fche, as usual

14:18 <fche> my pleasure, sorry not better news

17:59 <serhei> Another stap question, haven't been able to figure this out on my own

17:59 <serhei> What's the best way to probe a target process plus all its children?

18:02 <serhei> e.g. if I do "stap -ve 'probe process.function("*") { ... } -c 'gcc whatever.c'", it only seems to capture 7 function calls (the toplevel gcc process immediately forks and does all its work in children)

18:18 <serhei> Hmm, manual page says " Typing ``stap -c CMD'' or ``stap -x PID'' restricts this to the target command and descendants", but I'm not seeing anything happen with descendants.

18:18 <fche> that script is implicitly process("/path/to/gcc").function("*") { }

18:19 <fche> so if gcc forks off cc1 and as and ld and etc., those won't be the same process("/path/go/gcc")

18:19 <serhei> Makes sense

18:20 <serhei> The 'to descendants' part probably applies when you explicitly name an .so in the process probe

18:20 <serhei> like process("/lib64/libc-2.8.so").function("....") ..

18:21 <fche> or if gcc forks itself for some reason (/bin/sh) ... it -should- work that way