08:54 <promach> https://stackoverflow.com/questions/31463066/systemtap-script-to-profile-latency-of-functions have anyone used this to measure linux driver coding latency ?

08:54 <promach> note: I am new to systemtap

09:13 <promach> I think https://sourceware.org/systemtap/examples/profiling/linetimes.stp will help

09:36 <promach> Why am I facing this error https://paste.ubuntu.com/p/KyYfgFfcG9/ when using linetimes.stp ?

10:59 <fche> 'morning promac

10:59 <fche> promach I mean

10:59 <fche> you see two runs with two errors

11:00 <fche> linetimes requires detailed debuginfo because that's the only way to identify source lines in binary code

11:00 <fche> so in the first case, it's reporting that it can't find the kernel debuginfo, which is fine; # stap-prep or that readme file can usually fix that

11:01 <fche> in the second case, you typed "riffa", which it doesn't understand as a probe point name. See [man stapprobes] for the general syntax. e.g. if it's a kernel module riffa.ko you're trying to probe, use module("riffa") in that slot

12:35 <promach> use module("riffa") in that slot gives bash: syntax error near unexpected token `('

12:35 <promach> fche : sudo stap linetimes.stp module("riffa") push_circ_queue

12:39 <promach> fche: stap-prep gives : You need package linux-image-4.18.6-041806-generic-dbgsym but it does not seem to be available

13:11 <fche> module("riffa") would be the systemtap script language syntax

13:11 <fche> since you'd be passing it from a shell, you have to quote it: so 'module("riffa")'

13:12 <fche> check the README. sometimes you may be running very old or very new kernels, and your distro may not make the matching debuginfo available

13:18 <promach> To use systemtap you need to

13:18 <promach> manually install the linux-image-*-dbg and linux-header-* packages

13:18 <promach> that match your running kernel.

13:19 <fche> (To be accurate, that is to use -some- systemtap scripts. others do not require -dbg.)

13:19 <promach> no need to install for https://sourceware.org/systemtap/examples/profiling/linetimes.stp ?

13:20 <fche> it depends on the target program you're trying to trace lines/times of.

13:20 <fche> If it's the kernel, then yes you'll need kernel dbg stuff

13:20 <fche> with stap you can target any random userspace program too

13:21 <promach> what about linux module ?

13:21 <promach> such as riffa.ko ?

13:21 <fche> that'd need debuginfo only for that .ko file, which may already be compiled in

13:21 <fche> then you'd need the kernel header stuff only, not -dbg

13:21 <promach> ok

13:25 <promach> fche : https://paste.ubuntu.com/p/kTchnGptXQ/

13:25 <promach> this does not make sense

13:26 <fche> ok.

13:26 <promach> and my riffa.ko already contains debug symbol

13:26 <fche> where can systemtap find that copy of riffa.ko ?

13:26 <promach> since I included "-g" in compilation flag

13:26 <fche> Is it installed somewhere under /lib/modules/.... ?

13:27 <fche> if not, if it's in some private directory, then use 'module("/full/path/to/riffa.ko")' instead

13:27 <promach> /lib/modules/4.18.6-041806-generic/kernel/drivers/riffa/riffa.ko

13:28 <promach> fche: I just tried full path, same error

13:28 <fche> readelf -S /lib/modules/4.18.6-041806-generic/kernel/drivers/riffa/riffa.ko ?

13:30 <promach> fche : here you go: https://paste.ubuntu.com/p/NTjSSrNrns/

13:31 <promach> what does this output tell ?

13:32 <fche> tells us whether debuginfo is actually in the final .ko

13:32 <fche> and it isn't - there aren't any .debug* sections

13:32 <fche> one way to make more likely for the out-of-tree module to carry that info is to build it with make ... modules CONFIG_DEBUG_INFO=y

13:33 <promach> debuginfo != debug symbol ?

13:34 <fche> it is, but depending on how you put in "-g", some subsequent process may have stripped them out again

13:34 <fche> so, if the -g information is generated and preserved, that readelf -S should list a half-dozen .debug_* sections

13:34 <fche> and that stap script should work :)

13:38 <fche> does that make sense? also you could make V=1 to see closer the build process for your module

13:40 <promach> fche : what do you mean by "V=1" ?

13:42 <promach> note the -g at https://github.com/promach/riffa/blob/full_duplex/driver/linux/Makefile#L88

13:48 <fche> change line 101 to make -C $(KDIR) V=1 SUBDIRS=`pwd` modules

14:15 <promach> fche : sigh, I have done as you have suggested but readelf still does not print any "debug" word

14:15 <fche> do you have a trace of the V=1 make process?

14:15 <fche> so we can see whether the -g made it, and how far/

14:16 <fche> also you could try adjusting that line to say .... CONFIG_DEBUG_INFO=y

14:23 <promach> https://paste.ubuntu.com/p/7ny4SkMYxz/ fche

14:29 <fche> "

14:29 <fche> " sounds relevant

14:29 <fche> Stripping ELF binaries and libraries...OK

14:30 <fche> but the last readelf report looks good.

15:17 <wcohen> fche, is all thumbs. :)