00:04 <agentzh> k

00:11 <irker777> systemtap: yichun systemtap.git:master * release-4.2-109-g046b06a9e / NEWS runtime/linux/task_finder.c runtime/linux/task_finder2.c testsuite/systemtap.base/process-begin-user.exp testsuite/systemtap.base/process-begin-user_4.stp: feature: vma-related primitives now work in process.begin.

00:11 <fche> thanks dude

00:20 <agentzh> sure

00:33 <agentzh> fche: i wonder if it makes sense to cache target memory via fixed number of memory pages (through LRU) to speed up target memory read intensive stap scripts.

00:33 <agentzh> i did a simple experiment on my side and it achived 55% overall speedup for such a read-heavy scripts.

00:33 <agentzh> *achieved

00:35 <agentzh> my experiment was based on process_vm_readv + ptrace, it was 55% faster than the stap doing exactly the same thing against the same target process.

00:36 <agentzh> *the stap script

01:55 <fche> cache in what sense? we don't copy as it is

01:55 <fche> we don't swap either

01:55 <fche> what are you comparing exactly?

05:57 <hassan64> Hi all. I have been struggling to get this error fixed over the weekend. But unable to do that. Some thing missing in my Kernel. Please see my github https://gist.github.com/hassan113/9509989fc58bae3264e5795bd86b8cdd

06:04 <hassan64> In another *.stp file compilation, I got different error. Please help me out in both case. https://gist.github.com/hassan113/6b7fe299092fc7025085720ec4d6ebf9

06:05 <agentzh> fche: maybe it's just all the checks and boilerplate code around user_long_error() or other things. it's just counterintuitive that an efficient non-copying implementation of stap is so much slower than my naive ptrace-based copying implementation for the same thing.

06:08 <hassan64> fche: So well, how to tweak it in kernel to avoid such error

06:10 <agentzh> hassan64: maybe recompile your kernel with -Og and/or

06:10 <agentzh> -fvar-tracking?

06:10 <agentzh> it looks like a dwarf issue.

06:11 <agentzh> some times we can take advantage of the ABI and access registers and stack locations directly, bypassing dwarf.

06:12 <agentzh> $var does not always work especially when optimization is enabled.

06:12 <hassan64> so you mean, optimization needs to be disabled

06:13 <agentzh> not necessarily.

06:13 <agentzh> that's just one way.

06:13 <hassan64> And what about my second case: https://gist.github.com/hassan113/6b7fe299092fc7025085720ec4d6ebf9

06:13 <agentzh> i mentioned 3 ways above ;)

06:14 <agentzh> your 2nd case looks familiar to me.

06:14 <agentzh> maybe you have some old installs of stap hanging around.

06:14 <agentzh> you should remove your old installations of stap completely.

06:14 <agentzh> but maybe it's something else.

06:16 <agentzh> btw, are you cross-compiling?

06:16 <hassan64> yes cross-compiling

06:16 <agentzh> this looks familiar to me since i do cross-compiling a lot myself.

06:16 <hassan64> I am using systemtap ver: 4.2/0.177

06:16 <hassan64> seems to be a latest version

06:19 <hassan64> agentzh : I am using latest version rather

06:21 <hassan64> I am using "sudo make uninstall" to remove all.

06:22 <hassan64> and install systemtap from source again. ver: 4.2 and elfutils: 0.177

06:22 <agentzh> okay

06:22 <hassan64> by using : ./configure --with-elfutils=$(pwd)/../elfutils-0.177

06:22 <hassan64> make && make install

06:23 <agentzh> will you share your /tmp/stap5sgSgs/strace_src.c file as well? you'll need to use -k option and rerun stap though.

06:23 <agentzh> if there's nothing sensitive in your stap script.

06:28 <agentzh> it looks like a stap bug for new aarch64 kernels, see also here: https://sourceware.org/legacy-ml/systemtap/2018-q4/msg00061.html I'm not sure though.

06:29 <agentzh> it would be best to hear from other people more familiar with aarch64.

06:32 <hassan64> Thanks for the article. yesterday i compile kernel 4.19.91. And no issue at all.

06:33 <hassan64> But i thought latest kernel versions have more features, so I recompiled the latest ver, but that issue re-surfaced

06:33 <hassan64> so what do you think to recompile with old version as I did before. ?

07:00 <hassan64> agentzh: Can you please look at https://gist.github.com/hassan113/2fcf37c6d5e46fbe5b5fcf4c944fc7e2 . It contains strace_src.c

07:00 <hassan64> Any suggestion, should I rebuild with old kernel version

07:28 <hassan64> agentzh: Did you see it :)

09:19 <hassan64> fche: I remember you said last week how to install systemtap 4.2. I got an error. You said, first install elfutils individual and then configure systemtap vi a./configure LDFLAGS .....

09:20 <hassan64> sorry I forgot the step. And I missed the logs in this channel

10:34 <fche> hassan64, see the README file for guidance on that

10:40 <hassan64> fche: I do not know why I am getting this error. This is a new error so far . https://gist.github.com/hassan113/2fcf37c6d5e46fbe5b5fcf4c944fc7e2

10:41 <fche> yeah something must have changed

10:42 <hassan64> I am doing all the kernel configuration, which I did for aarch machine. But something went wrong

10:43 <fche> try stap -gv -a arm -p4 -r /home/hassan/Desktop/sandbox_design/armv5/output/build/linux-4.19.91/ -B CROSS_COMPILE=/home/hassan/Desktop/sandbox_design/arm/output/host/bin/arm-linux- -vvvv -L 'kernel.trace("sys_enter")'

11:01 <hassan64> fche: https://gist.github.com/hassan113/2fcf37c6d5e46fbe5b5fcf4c944fc7e2

13:22 <hassan64> My compilation from *.stp -> *.ko fails

13:23 <hassan64> please see my output. https://gist.github.com/hassan113/2fcf37c6d5e46fbe5b5fcf4c944fc7e2

13:32 <irker479> systemtap: fche systemtap.git:fche/uprobes-rework * release-4.2-103-g7d2fafc9d / buildrun.cxx translate.cxx: gcc compatibility: use gcc #pragma to suppress -Wtautological-compare

13:32 <irker479> systemtap: fche systemtap.git:fche/uprobes-rework * release-4.2-104-ge8ebc3ff9 / runtime/linux/uprobes-inode.c tapsets.cxx: TENTATIVE uprobes-inode: rework

13:32 <fche> serhei et al., would appreciate a glance at the work in that branch

15:12 <irker479> systemtap: fche systemtap.git:fche/uprobes-rework * release-4.2-106-ga1bbefd79 / configure configure.ac: configury: adjust -lebl check to ebl_strtabinit

15:12 <irker479> systemtap: smakarov systemtap.git:fche/uprobes-rework * release-4.2-107-g1eaeb16df / buildrun.cxx runtime/linux/autoconf-kallsyms-on-each-symbol.c runtime/linux/kprobes.c runtime/linux/runtime.h runtime/sym.c runtime/sym.h runtime/transport/symbols.c runtime/transport/transport.c runtime/transport/transport.h runtime/transport/transport_msgs.h staprun/staprun.c translate.cxx: PR26074: pass kallsyms_lookup_name as a relocation to the

15:12 <irker479> systemtap: yichun systemtap.git:fche/uprobes-rework * release-4.2-108-g26b24dc2e / : Bug: tapset functions reading userland registers did not work in probe process.begin

15:12 <irker479> systemtap: yichun systemtap.git:fche/uprobes-rework * release-4.2-109-g046b06a9e / NEWS runtime/linux/task_finder.c runtime/linux/task_finder2.c testsuite/systemtap.base/process-begin-user.exp testsuite/systemtap.base/process-begin-user_4.stp: feature: vma-related primitives now work in process.begin.

15:12 <irker479> systemtap: smakarov systemtap.git:fche/uprobes-rework * release-4.2-112-g9d389223c / : Merge branch 'master' into fche/uprobes-rework

19:58 <irker479> systemtap: fche systemtap.git:fche/uprobes-rework * release-4.2-113-ga8a6cd268 / runtime/linux/uprobes-inode.c: move buildid check prior to stapiu consumer_lock

20:46 <agentzh> fche: how about this patch? https://gist.github.com/agentzh/1e5204dab98e6b4b3f7ade53109c5fff i forgot one place for reordering the task finder callback calls.

20:48 <fche> sure

22:16 <agentzh> fche: thanks, will commit.

22:23 <irker479> systemtap: yichun systemtap.git:master * release-4.2-110-g85bbcefbe / runtime/linux/task_finder2.c: Bug: __stp_tf_quiesce_worker(): vma mmap callback incorrecty ran after process.begin callback