Hi I am using llvm-dwarfdump to dump the line table with -debug-line option. I compiled my program with -gdwarf-3. I first get the line number and source number for every instruction of the LLVM IR with metadata. Then I try to find the corresponding binary address from the dwarf debug info. However, I noticed that the dwarf table might not always return me the answer and some of the source line and column number is not found inside dwarf table. Do anyone have the same experiences? How do you handle this case. Many Thanks Regards Muhui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180522/de487a6e/attachment.html>
Adrian Prantl via llvm-dev
2018-May-22 16:02 UTC
[llvm-dev] LLVM dwarf info is not complete
> On May 22, 2018, at 8:06 AM, Muhui Jiang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi > > I am using llvm-dwarfdump to dump the line table with -debug-line option. I compiled my program with -gdwarf-3. > > I first get the line number and source number for every instruction of the LLVM IR with metadata. Then I try to find the corresponding binary address from the dwarf debug info. However, I noticed that the dwarf table might not always return me the answer and some of the source line and column number is not found inside dwarf table.The mapping between source locations and binary addresses is not bijective, especially so when the compiler performs any optimizations. To give an obvious example, when the compiler performs dead code elimination, the source locations of the dead code will not appear in the debug info for the resulting binary. Another common example is when two identical instructions with different debug locations are merged. DWARF cannot express more than one source location for a given binary address, so LLVM intentionally drops the debug location in this case. If you want to better understand what the compiler is doing and why some source locations go missing, I recommend generating the smallest possible reproducer of your problem and then compiling the program with -print-after-all (in clang: -mlllvm -print-after-all). This will dump the intermediate representation after each compiler pass and will allow you to pinpoint the step where the source location you are interested in is being dropped. With that information you can then decide whether that is a bug in LLVM (quite possible) or whether the debug information is legitimately lost because of the nature of the transformation. -- adrian> > Do anyone have the same experiences? How do you handle this case. Many Thanks > > Regards > Muhui > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Adrian Thanks for your very clear and detail explanation. I think I've already known the reason. Thank you so much Regards Muhui 2018-05-23 0:02 GMT+08:00 Adrian Prantl <aprantl at apple.com>:> > > On May 22, 2018, at 8:06 AM, Muhui Jiang via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi > > > > I am using llvm-dwarfdump to dump the line table with -debug-line > option. I compiled my program with -gdwarf-3. > > > > I first get the line number and source number for every instruction of > the LLVM IR with metadata. Then I try to find the corresponding binary > address from the dwarf debug info. However, I noticed that the dwarf table > might not always return me the answer and some of the source line and > column number is not found inside dwarf table. > > The mapping between source locations and binary addresses is not > bijective, especially so when the compiler performs any optimizations. To > give an obvious example, when the compiler performs dead code elimination, > the source locations of the dead code will not appear in the debug info for > the resulting binary. Another common example is when two identical > instructions with different debug locations are merged. DWARF cannot > express more than one source location for a given binary address, so LLVM > intentionally drops the debug location in this case. > > If you want to better understand what the compiler is doing and why some > source locations go missing, I recommend generating the smallest possible > reproducer of your problem and then compiling the program with > -print-after-all (in clang: -mlllvm -print-after-all). This will dump the > intermediate representation after each compiler pass and will allow you to > pinpoint the step where the source location you are interested in is being > dropped. With that information you can then decide whether that is a bug in > LLVM (quite possible) or whether the debug information is legitimately lost > because of the nature of the transformation. > > -- adrian > > > > Do anyone have the same experiences? How do you handle this case. Many > Thanks > > > > Regards > > Muhui > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180523/1ea14e06/attachment.html>