Re: Fixing stack trace function names by argument introspection


Yonghong Song
 

On Tue, Jul 24, 2018 at 9:06 AM, marko@... <marko@...> wrote:


On Mon, Jul 23, 2018 at 7:48 AM, Y Song <ys114321@...> wrote:


We did not have such an example in BCC. In Facebook, we have a bpf
program to catch
stack traces for python programs. It is very similar to what you want
to achieve in the above.

Can you share it with me? Maybe I can use it as an example.
It is a piece of complicated software, let me see how much I can do.



Basically, you need to walk the stack by yourself. Since verifier do
not support unbounded loops,
you need to have a fully-unrollable loop with progma unroll.

I have never used pragma unroll before, but I understand what it is supposed
to do.
Quick search gives me usages for CUDA and several little known examples for
gcc/clang.
Are you talking about them?
https://stackoverflow.com/questions/4071690/tell-gcc-to-specifically-unroll-a-loop
Yes, it is `#pragma unroll`.



During each loop iteration, you can access the frame pointer, you need
some mechanism to
get the real function name based on that level frame pointer and then
you move on
to the next. In bpf program, you can access current task structure,
which contains some
data related to TLS which could be used by the bpf program.
As far as I understand it would work if my program is built with frame
pointers. In that case going throigh stack trace shold be straightforward.
Never done it before though :-)
Not 100% whether just frame pointers are enough for you or not.
Remeber, on the stack, typically only frame pointer (if available),
function return address, spills, and #7 and later arguments.
It is very likely the case that `fn_name` in `execute_fn(fn_name)` may
not on the stack and you need to find a different way to access it.

But usually programs are build omitting frame pointers. In that case you
need additional info from DWARF and code is much more complex. Right?
Are you suggesting implementing all this?
We are talking about stack walking inside bpf programs, dwarf option is
certainly out of question. In that case, you may need to use
perf record dwarf...


Sorry for newbie questions :-)

Join iovisor-dev@lists.iovisor.org to automatically receive all group messages.