<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 30, 2013 at 8:58 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr"><br>
On Oct 30, 2013 7:25 PM, "Philip Reames" <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:<br>
><br>
> On 10/30/13 7:09 PM, Philip Reames wrote:<br>
>><br>
>> David, Quentin - Thanks for the feedback.  Responses inline.<br>
>><br>
>> On 10/30/13 11:21 AM, David Blaikie wrote:<br>
>>><br>
>>> Actually CCing Eric.<br>
>>><br>
>>><br>
>>> On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>> wrote:<br>
>>>><br>
>>>> Philip,<br>
>>>><br>
>>>> Thanks for the clarification.<br>
>>>><br>
>>>> As far as I can tell, there is currently no way to preserve a full and accurate stack trace while utilizing most of LLVM’s optimization abilities.<br>
>>>><br>
>>>> The work on debug information may help you get the information you need, but I do not think we will provide information on stack frames that have been removed via inlining or tail call.<br>
>>><br>
>>><br>
>>> In theory, at -gmlt we should emit enough debug info to give you accurate stack traces including inlined frames. Tail calls I assume we can't do anything about.<br>
>><br>
>> Tail calls I'm not too worried about.  I'm reasonably sure that our existing optimizer doesn't do any tail call optimizations.  Given that, turning them off doesn't worry me too much performance wise.<br>


>><br>
>> First, thank for you for mentioning the -gmit option.  I had been completely unaware of that.  I'll have to dig into the implementation and usage a bit.  Can you point me to any documentation?  A quick google search didn't turn up anything. <br>


>><br>
>> 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?)<br>


><br>
> 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.  <br>
</p></div></div></blockquote><div>(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".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr">

></p>
</div></div><p dir="ltr">It should yes. Any time where it can't is a bug in either our implementation or in DWARF itself. :)</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">-eric<br>
</p>
</font></span><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>