18:05 <__positron> I am trying to compile a script with 'print_ubacktrace'. kernel version is >=3.5 (v4.8.4). However, stap complains with "user-space process-tracking facilities not available"

18:06 <__positron> I grepped through the source code to see that stap expects 'CONFIG_UTRACE' to be set. However, the kernel sources doesn't have anything like that.

18:07 <__positron> According to https://sourceware.org/systemtap/wiki/utrace, recent kernels (>=3.5) has most of the necessary infrastructure for utrace. what am I missing?

18:08 <__positron> Should I pull in utrace patches manually and rebuild my kernel?

18:16 <fche> CONFIG_UPROBES

18:18 <__positron> Rebuilding the kernel...

18:18 <__positron> Why are the sources still checking for 'UTRACE'?

18:18 <fche> because the sources work against very old kernels too

18:18 <__positron> Is it for backward compatibility?

18:18 <fche> and new ones

18:19 <__positron> Shouldn't there be a more saner check by comparing the kernel version?

18:19 <fche> utrace never went upstream, so there is no standard upstream kernel version number we can check against

18:20 <__positron> What are UPROBES then?

18:20 <fche> https://lwn.net/Articles/499190/

18:23 <__positron> I hope I'd be able to use 'print_ubacktrace' with CONFIG_UPROBES set. That brings me back to the same question, shouldn't this be handled in the code automatically? Like, search for UTRACE, if not found, be content with UPROBES?

18:23 <fche> the code is content with CONFIG_UPROBES

18:25 <fche> could you transcribe your script & error message & maybe even the info collected by stap-report (pastbin the latter, it's big)

19:44 <__positron> fche: Thanks, It works after recompilation. I was in a premise that the error was originating from buildrun.cxx:uprobes_pass, which was actually checking for CONFIG_UTRACE.

19:45 <fche> that's a separate creature, only used on very old kernels

19:45 <fche> glad you got it working though, good job!

19:45 <jistone> (very old... including rhel6 *sigh*)

20:29 <fche> hey, rhel6 provides much customer value and pays many salaries :-)

21:07 <jistone> oh I know. I think recent stats showed that EPEL6 is much more accessed than EPEL7 or all of Fedora