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

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

Hi Adrian

Thanks for your very clear and detail explanation. I think I’ve already known the reason. Thank you so much

Regards
Muhui