Philip Reames
2013-Oct-31 02:25 UTC
[LLVMdev] Preserving accurate stack traces with optimization?
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 <mailto: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. Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20131030/c4e95bd8/attachment.html>
Eric Christopher
2013-Oct-31 03:58 UTC
[LLVMdev] Preserving accurate stack traces with optimization?
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 andaccurate stack trace while utilizing most of LLVM’s optimization abilities.>>>> >>>> The work on debug information may help you get the information youneed, 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 youaccurate 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 ourexisting 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 beencompletely 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 correctspelling) 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.>It should yes. Any time where it can't is a bug in either our implementation or in DWARF itself. :) -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20131030/a33558e7/attachment.html>
Alexey Samsonov
2013-Oct-31 20:54 UTC
[LLVMdev] Preserving accurate stack traces with optimization?
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 llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20131031/88f01066/attachment.html>
Reid Kleckner
2013-Oct-31 21:17 UTC
[LLVMdev] Preserving accurate stack traces with optimization?
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. > > > > It should yes. Any time where it can't is a bug in either our > implementation or in DWARF itself. :) >What about tail calls? I didn't think we knew how to handle that. -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20131031/92a7be96/attachment.html>
Maybe Matching Threads
- [LLVMdev] Preserving accurate stack traces with optimization?
- [LLVMdev] Preserving accurate stack traces with optimization?
- [LLVMdev] Preserving accurate stack traces with optimization?
- [LLVMdev] Preserving accurate stack traces with optimization?
- [LLVMdev] Preserving accurate stack traces with optimization?