Support tail calls in stack traces

[kuznet9]

Absence of tail call unwinding makes kernel crash analysis very difficult, in most of cases just impossible. Unfortunately tail calls are massively used in kernel. F.e. see attached examples: kernel module test.c and user space testu.c.
examples.zip

gdb understand it just fine:

(gdb) bt
#0  __printf (format=format@entry=0x402010 "%d\n") at printf.c:28
#1  0x00000000004011b3 in a (b=b@entry=0x7fffffffe3f0) at testu.c:10
#2  0x00000000004011c7 in b (x=x@entry=0x7fffffffe3f0) at testu.c:16
#3  0x00000000004011d7 in c (x=x@entry=0x7fffffffe3f0) at testu.c:21 

And drgn:

>>> trace
#0  context_switch (kernel/sched/core.c:5296:2)
#1  __schedule (kernel/sched/core.c:6609:8)
#2  schedule (kernel/sched/core.c:6685:3)
#3  schedule_timeout (kernel/time/timer.c:2167:2)
#4  msleep (kernel/time/timer.c:2322:13)
#5  a (/root/testmod/test.c:18:3)
#6  test_work (/root/testmod/test.c:41:2)
#7  kthread (kernel/kthread.c:376:9)
#8  ret_from_fork+0x1f/0x2a (arch/x86/entry/entry_64.S:308)

See? Unless we knew about path from test_work -> a, we would never find it.

[osandov]

Thanks (especially for the example). To support this, drgn needs to look for DW_TAG_call_site entries when assembling the frames for a stack trace (note to self: section 3.4.1 "Call Site Entries" in the DWARF 5 spec). I added it to the roadmap.