[LLVMdev] Preserving accurate stack traces with optimization?

[Alexey Samsonov]

On Wed, Oct 30, 2013 at 8:58 PM, Eric Christopher <echristo at gmail.com>wrote:

>
> On Oct 30, 2013 7:25 PM, "Philip Reames" <listmail at philipreames.com>
> wrote:
> >
> > On 10/30/13 7:09 PM, Philip Reames wrote:
> >>
> >> David, Quentin - Thanks for the feedback.  Responses inline.
> >>
> >> On 10/30/13 11:21 AM, David Blaikie wrote:
> >>>
> >>> Actually CCing Eric.
> >>>
> >>>
> >>> On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet <
> qcolombet at apple.com> wrote:
> >>>>
> >>>> Philip,
> >>>>
> >>>> Thanks for the clarification.
> >>>>
> >>>> 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.
> >>>>
> >>>> 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.
> >>>
> >>>
> >>> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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".


> >
>
> It should yes. Any time where it can't is a bug in either our
> implementation or in DWARF itself. :)
>
> -eric
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131031/88f01066/attachment.html>