Re: Systemtap kernel backtraces not working on 4.14.14

[fche@redhat.com (Frank Ch. Eigler)]

avi wrote:

> I have a centos installation with 4.14.14 installed [...]
>   at:       8483   to: rcu_sched
>  0xffffffffa0335150 : 0xffffffffa0335150
> [stap_fc3e91a0b756c0a804d73b3d051959b6__1891+0xd150/0x0]
>  0xffffffffa0336476 : 0xffffffffa0336476
> [...]

Ouch.

> Is there something in the kernel configuration I need to turn on
> (.config taken from elrepo's -ml kernel)? Or a missing dependency
> while building systemtap? 

Shouldn't be the case.

> Maybe systemtap can't cope with retpolines?

systemtap's backtrace engine uses dwarf unwind information.  In
principle, retpolines should be representable properly, but in practice,
there may be some problems with some compilers [1] or some kernel-side
asm .cfi annotations.  I don't currently anticipate systemtap having to
change, but these tools do need to produce correct output.

[1]  https://gcc.gnu.org/ml/gcc/2018-01/msg00160.html

As your kernel seems to be hand-built, and we don't have retpoline
kernels already in circulation, so it'll be tricky to reproduce the
problem here.  Running stap with -DDEBUG_UNWIND=3 would let us see its
point of view.  Try also backtracing from other probe points to see how
systemic the problem is.  It may also help to let us get hold of your
kernel & its build vitals (esp. gcc version).

- FChE