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

Having a different code path for prologue just for the sanitizers sounds pretty
risky to me. That code is already strewn with conditional and modal stuff.
Adding another variable to the permutations scares me. Is there really no
alternative? Conditional code in the sanitizers that figure things out? LLDB and
GDB have a very similar sort of problem for backtraces, including when debug
info isn’t available. How do they solve it?

-Jim

> On Jul 18, 2014, at 8:01 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> On 17 July 2014 21:08, Reid Kleckner <rnk at google.com> wrote:
>> Would they be willing to have a flag?  Would we be willing to have a
flag?
> 
> That's a good question. Anything we do would be easier than wait for
> them to do anything, so if we decide to go with a flag, it should be
> us implementing.
> 
> 
>> Or should we conditionalize this on OS and say, on Linux, do the gcc
thing,
>> and on OS X, do the LLVM thing?
> 
> I think you agree with me that both solutions are ugly, but I'd rather
> not make this default behaviour anywhere, so that only who needs it
> (sanitizers) turns it on with a flag.
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 18 July 2014 17:49, Jim Grosbach <grosbach at apple.com>
wrote:
> Having a different code path for prologue just for the sanitizers sounds
pretty risky to me. That code is already strewn with conditional and modal
stuff. Adding another variable to the permutations scares me.
Same here.

> Is there really no alternative? Conditional code in the sanitizers that
figure things out? LLDB and GDB have a very similar sort of problem for
backtraces, including when debug info isn’t available. How do they solve it?
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.

GDB has a lot of hidden context with GCC that only works because their
development roadmaps are tied together and it's more scaring than
that, but I don't know how they chose to use magic or not.

cheers,
--renato

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>