[llvm-dev] LLVM dwarf info is not complete

[Muhui Jiang via 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>