09:08 <lorddoskias1> http://paste.ubuntu.com/23181402/

09:08 <lorddoskias1> what's the issue here?

09:08 <lorddoskias1> i mean clearly the ioblock_request probe point doesn't know what type bdev is

09:11 <lorddoskias1> in bdevname there is already: bdev = & @cast(bdev, "block_device") so bdev should be of known type ?

10:00 <lorddoskias1> fche: any ideas?

10:00 <lorddoskias1> :)

10:59 <fche> hi lord

11:02 <fche> sorry, it's not jumping out at me ... obviously some info is missing, but we're not helping well to find it

11:02 <fche> try a little more verbosity (stap --vp 03 ....) say

11:03 <fche> does that 4.1.14-clouder5 vmlinux image have debuginfo/etc. retained ?

11:04 <lorddoskias1> yes indeed, it does

11:04 <lorddoskias1> let me try it

11:04 <lorddoskias1> also one more thing

11:05 <lorddoskias1> if i want to set a probe on a trace point e.g. kernel.trace("block_issue_request")

11:05 <lorddoskias1> is there a way to access the various "args" that the tracepoint prints?

11:05 <lorddoskias1> or no way?

11:08 <lorddoskias1> fche: http://paste.ubuntu.com/23181790/

11:16 <fche> oh sure there's a way

11:17 <fche> [man stapprobes] search for KERNEL TRACEPOINTS

11:19 <lorddoskias1> right

11:19 <lorddoskias1> still, i'd like to use whatever is provided by stapruntime :)

11:19 <fche> the tapset? yeah

11:19 <fche> but if something's up with the debuginfo/symbol-tables, yeah the kernel tracepoints are a great alternative

11:19 <lorddoskias1> eyeah, but it's giving me error

11:20 <fche> and really the tapset should prefer it (and does in other spots) over time

11:20 <lorddoskias1> but the debug symbols should be good

11:20 <lorddoskias1> since doing stap -L 'kernel.statement("generic_make_request@*:*")'

11:20 <lorddoskias1> prints what's at the particular line

11:20 <fche> yup

11:21 <lorddoskias1> ops

11:21 <lorddoskias1> maybe i was too hasty

11:34 <lorddoskias1> so fche stap -dkernel -r4.4.14-clouder5 -BCC=/opt/rh/devtoolset-3/root/usr/bin/gcc -L 'kernel.statement("generic_make_request@*:*")' this command works like a charm

11:34 <lorddoskias1> this one doesn't stap -dkernel -r4.4.14-clouder5 -BCC=/opt/rh/devtoolset-3/root/usr/bin/gcc block-trace.stp

12:21 <fche> hey lorddoskias1

12:21 <fche> any progress/luck ?

12:21 <lorddoskias1> nope

12:21 <lorddoskias1> as i said listing symbols work

12:21 <lorddoskias1> but when i try to compile the script - error

12:21 <fche> -L statement stuff relies on debuginfo, it's good that this works

12:22 <fche> I wonder if perhaps our implementation of @cast() doesn't do the right thing with respect to cross-compiled (-rXXXX) runs

12:27 <lorddoskias1> hm, maybe

21:29 <irker289> systemtap: dsmith systemtap.git:refs/heads/dsmith/python * release-3.0-246-ge5d623b / Makefile.in configure configure.ac doc/Makefile.in doc/SystemTap_Tapset_Reference/Makefile.in doc/beginners/Makefile.in dtrace.in java/Makefile.in man/Makefile.in man/cs/Makefile.in python/Makefile.in stapdyn/Makefile.in staprun/Makefile.in: Added autoconf logic to search for python version 2 and 3. http://tinyurl.com/heybnre

21:51 <bendlas> i tried to use systemtap-3.0 against kernel 4.7.3, but I get compilation errors during runtime.

21:51 <fche> you'll need git systemtap to work against newer kernels

21:51 <bendlas> OIC

21:51 <bendlas> is master good to track?

21:51 <fche> yessir

21:52 <bendlas> cool, I'll try that

22:01 <bendlas> woot, it works

22:01 <bendlas> now we can have a working systemtap in nixos again :-)

22:01 <bendlas> thanks, fche

22:01 <fche> ship it!

22:01 <fche> ship it NOW

22:02 <bendlas> I only have to cross-check the failure mode for when DEBUG_INFO is missing from the kernel

22:02 <fche> we don't call that failure

22:02 <fche> we call that success in a different way :-)

22:03 <bendlas> oh, so it works with reduced functionality?

22:03 <bendlas> that's even better

22:03 <fche> quite a bit works -- see [man stapprobes] for DWARF

22:03 <bendlas> let me just boot a vm w/o DEBUG_INFO, real quick

22:03 <fche> not everything

22:07 <bendlas> btw, do you think it's worth it, to separate out debug data, like fedora does?

22:07 <fche> debuginfo is a godsend if one needs to debug

22:07 <fche> it's a waste of disk space if one never does

22:07 <bendlas> IE, can a production kernel be compiled with DEBUG_INFO, and yet be the same as w/o after stripping?

22:08 <fche> that's what fedora/rhel-style debuginfo splitting does

22:09 <bendlas> can systemtap take advantage of more of the extra debug flags from rawhide?

22:09 <fche> you may be referring to kernel-devel-* builds, wherein more self-instrumentation is compiled into the kernel

22:09 <fche> that's an orthogonal thing, stap is not involved in that

22:09 <bendlas> ie, should we provide a separate debug kernel for some use cases of systemtap, or is just debug_info good enough?

22:10 <bendlas> oh, that's good

22:10 <fche> -debug- kernels usually cost you speed but give better diagnostics/checking

22:10 <fche> kernel -debuginfo lets tools like systemtap debug kernels (and kernel-debug- kernels)

22:10 <fche> orthogonal

22:10 <bendlas> I'll consider pushing for an additional `debugInfo` output in our default kernel build, if the regular user won't be affected

22:11 <fche> dwarf debuginfo carries no runtime overhead at all, by design, for a good compiler like gcc

22:11 <fche> https://archive.fosdem.org/2016/schedule/event/where_are_your_symbols_debuginfo_and_sources/ <-- see also

22:12 <bendlas> yeah, I remember having heard that about dwarf

22:13 <bendlas> so, fedora also provides extra debuginfo downloads for most (all?) of userland?

22:13 <fche> yup.

22:13 <bendlas> that's pretty cool, we should also provide that in nixos

22:13 <fche> if you build your own kernel, to be systemtap-friendly, consider also carrying

22:14 <fche> http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/Kbuild-Add-an-option-to-enable-GCC-VTA.patch

22:14 <bendlas> we just got userland hardening merged, so it might be a good time to think about debuginfo

22:14 <fche> unfortunately linus was misguided about gcc -g -fvar-tracking-assignments two years ago, and it stuck :(

22:16 <bendlas> he didn't want the debuginfo bloat?

22:16 <fche> it wasn't bloat

22:16 <fche> that URL explains well

22:16 <bendlas> yep

22:17 <bendlas> but it was about the size?

22:17 <fche> the gcc VTA issue was about concern about a shortlived gcc bug wherein that DWARF option could break normal code generation

22:17 <fche> it was fixed in a day ... but VTA was not reenabled in the mainstream kernel :-(

22:17 <bendlas> i see

22:18 <fche> anyway

22:18 <bendlas> thanks for the tips

22:18 <fche> np

22:36 <bendlas> btw, https://sourceware.org/systemtap/wiki/SystemTapWithSelfBuiltKernel states, that it cannot handle split debug info

22:37 <bendlas> I suppose, that's outdated info?

22:53 <jistone> bendlas, no, that's true

22:53 <jistone> split, as in *.dwo files

22:53 <jistone> it certainly supports split the way distros like fedora do it

22:54 <bendlas> i see