Messages in this thread | | | Date | Wed, 15 Jul 2015 10:55:36 -0400 | From | Steven Rostedt <> | Subject | Re: [RFC 2/3] arm64: refactor save_stack_trace() |
| |
On Wed, 15 Jul 2015 20:41:34 +0900 AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> Thank you for the explanation. But what I don't really understand here > is why we need to add the "current function" to the stack dump list > returned by save_stack_trace(): > > In check_stack(), > > /* > > * Add the passed in ip from the function tracer. > > * Searching for this on the stack will skip over > > * most of the overhead from the stack tracer itself. > > */ > > stack_dump_trace[0] = ip; > > max_stack_trace.nr_entries++; > > I think that "ip" here is the "return address for func" in your
Ah, you are correct (for fentry).
> ascii art, and it should be already in the list if a frame is made > by mcount (or func_call). > > In fact, stack tracer on arm64 works OK even without the patch[3/3] > if the code quoted above is commented out. > Even on x86, the code is conditional and not activated if the kernel > is compiled without -mfentry before the following commit: > commit 4df297129f62 ("tracing: Remove most or all of stack tracer stack size from stack_max_size") > > So what do I misunderstand here? >
Hmm, I haven't touched the stack trace code in a while. With the added stack frame for fentry, the hacks there are probably not needed.
I'll take a look at it and try to clean up the code.
Thanks,
-- Steve
| |