[LLVMdev] Preserving accurate stack traces with optimization?

[Philip Reames]

On 10/31/13 1:54 PM, Alexey Samsonov wrote:
>
> On Wed, Oct 30, 2013 at 8:58 PM, Eric Christopher <echristo at gmail.com 
> <mailto:echristo at gmail.com>> wrote:
>
>
>     On Oct 30, 2013 7:25 PM, "Philip Reames"
>     <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>     >
>     > On 10/30/13 7:09 PM, Philip Reames wrote:
>     >> Can you clarify two things for me?  First, is the intent that
>     -gmit *always* provide accurate stack traces?  (modulo bugs of
>     course)  If so, what is your subjective opinion on how close it
>     comes to meeting that goal today?  (i.e. how much help would we
>     need to contribute to get it to a solid state?)
>     >
>     > David - Redoing my google searching with "gmlt" (i.e. the
>     correct spelling) I see more useful links.  From what I can
>     gather, -gmlt emits a strict subset of the debug information you'd
>     see at -g. Are you saying that "-g" should always be sufficient
>     for accurate stack traces - even in the face of inlining?  This
>     would be ideal for us.
>
> (side note: Clang option is spelled as -gline-tables-only). Both -g 
> and -gline-tables-only should contain the information needed to get 
> the stack trace with inlining (at -O2 and higher). We actually rely on 
> that in sanitizer tools. As David mentioned, we build the code with 
> -O2 and -gline-tables-only and use llvm-symbolizer to get stack traces 
> at runtime. You may also try "addr2line -i".
Glad to hear.  Given this sounds like a supported use, we'll probably 
run with this.  I expect we'll find our own set of bugs and have to 
report/fix them, but knowing there are others out there supporting 
similar use cases is highly comforting.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131031/bb8dc45a/attachment.html>