llvm dev - May 2018 - LLVM dwarf info is not complete

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>

> 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>