[PATCH] D16697: Updating .debug_line section version information to match DWARF version.

[Adrian Prantl via cfe-commits]

> On Jan 28, 2016, at 4:57 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> +Adrian for Apple/LLDB perspective
> 
> One way to merge the tests would be to add another command line argument into DwarfDebug (see the way the split-dwarf command line argument is used), just for testing purposes. The command line argument can override the value specified in the metadata - so you can have one input file for the 3 different versions.




> 
> On Thu, Jan 28, 2016 at 4:28 PM, Katya Romanova via cfe-commits <cfe-commits at lists.llvm.org <mailto:cfe-commits at lists.llvm.org>> wrote:
> kromanova created this revision.
> kromanova added reviewers: dblaikie, echristo, probinson.
> kromanova added a subscriber: cfe-commits.
> kromanova set the repository for this revision to rL LLVM.
> 
> Hello,
> The compiler always emits .debug_line version 2, though some opcodes from DWARF 3 (e.g. DW_LNS_set_prologue_end, DW_LNS_set_epilogue_begin or DW_LNS_set_isa) and from DWARF 4 could be emitted by the compiler. That's not exactly right.
> 
> This patch changes version information of .debug_line to exactly match the DWARF version (which is 4 by default).
> For .debug_line version 4, a new field maximum_operations_per_instruction is emitted. I'm not exactly sure how to set this field correctly for VLIW architectures. Hopefully, there are some experts in the community that could help out (any Hexagon debuginfo developers out there?).
> 
> I’ve tried a few tools to check if they could handle .debug_line version 4.
> On a simple testcase, I verified that GDB debugger 7.7 understands .debug_line version 4.
> Sony’s proprietary debugger can understand it too.
> I don't have LLDB built, so I haven’t tried it.

There is now a public bot that runs the LLDB testsuite on Darwin (http://lab.llvm.org:8080/green/job/LLDB/) so you’ll find out immediately :-)
LLDB can be fixed, I’m not too worried about it.

There are, however, also DWARF consumers that are not debuggers that will read the line table, such as CoreSymbolication (atos(1)). I’ll investigate whether it can digest the newer version and follow up here.
If it doesn’t it would be best to either make this a separate option or to special-case Darwin.

-- adrian

> GCC (older version 4.8.2) still emits version 2 for the .debug_line section, even though the DWARF version is set to 4. I'm not sure about the latest GCC.
> GNU's readelf (version 2.24) can handle .debug_line version 4.
> 
> I added 3 new tests debug-line-version2.ll, debug-line-version3.ll and debug-line-version4.ll. The IR is generated from one source using different options (-gdwarf-2, -gdwarf-3 and –gdwarf-4). Any idea how to merge these three tests into one?
> 
> Let me know what do you think about the patch.
> 
> 
> Repository:
>   rL LLVM
> 
> http://reviews.llvm.org/D16697 <http://reviews.llvm.org/D16697>
> 
> Files:
>   lib/MC/MCDwarf.cpp
>   test/DebugInfo/AArch64/line-header.ll
>   test/DebugInfo/Generic/debug-line-version2.ll
>   test/DebugInfo/Generic/debug-line-version3.ll
>   test/DebugInfo/Generic/debug-line-version4.ll
>   test/DebugInfo/Generic/empty.ll
>   test/DebugInfo/X86/empty.ll
>   test/DebugInfo/X86/stmt-list-multiple-compile-units.ll
>   test/MC/ELF/debug-line.s
>   test/MC/ELF/debug-line2.s
>   test/MC/ELF/debug-loc.s
>   test/MC/ELF/discriminator.s
>   test/MC/ELF/empty-dwarf-lines.s
>   test/MC/MachO/file.s
>   test/MC/MachO/gen-dwarf.s
>   test/MC/MachO/loc.s
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org <mailto:cfe-commits at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160128/a8c919c3/attachment.html>