llvm dev - Jul 2014 - [LLVMdev] GCC/LLVM frame pointer incompatibility on ARM

On Fri, Jul 18, 2014 at 2:11 PM, Renato Golin <renato.golin at linaro.org>
wrote:
>
> The alternative is to use the unwind tables that both GCC and LLVM
> generate even on C code, and that the ABI tells us to use, but their
> argument is that's too slow. I don't know LLDB, but GDB uses
tables,
> but also the hidden logic (for faster unwinding), so I guess that with
> code produced by LLVM, it just uses the tables.
>
It's not just sanitizers that need to be able to get fast, accurate stack
traces.  Consider sampling profilers that capture call stacks.  Using the
unwind tables is disruptively slow to the process under profile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140718/35a0aed3/attachment.html>

> On Jul 18, 2014, at 4:55 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Fri, Jul 18, 2014 at 2:11 PM, Renato Golin <renato.golin at
linaro.org> wrote:
> The alternative is to use the unwind tables that both GCC and LLVM
> generate even on C code, and that the ABI tells us to use, but their
> argument is that's too slow. I don't know LLDB, but GDB uses
tables,
> but also the hidden logic (for faster unwinding), so I guess that with
> code produced by LLVM, it just uses the tables.
> 
> It's not just sanitizers that need to be able to get fast, accurate
stack traces.  Consider sampling profilers that capture call stacks.  Using the
unwind tables is disruptively slow to the process under profile.
Why not do the unwind table parsing after the fact? Especially for a profiler,
there’s no reason to do that during the actual profile collection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140718/2d61533e/attachment.html>

On Fri, Jul 18, 2014 at 4:59 PM, Jim Grosbach <grosbach at apple.com>
wrote:
> It's not just sanitizers that need to be able to get fast, accurate
stack
> traces.  Consider sampling profilers that capture call stacks.  Using the
> unwind tables is disruptively slow to the process under profile.
>
>
> Why not do the unwind table parsing after the fact? Especially for a
> profiler, there’s no reason to do that during the actual profile
collection.
>
I'm not sure how that would work, without memcpy-ing the entire stack.  If
you don't have frame pointers you can't walk upwards to find the return
addresses to save, at least not without... looking at the unwind tables.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140718/f4b67116/attachment.html>