[PATCH] D49214: [DWARF v5] emit DWARF v5 range lists (no support for fission yet)

[Paul Robinson via Phabricator via llvm-commits]

probinson added inline comments.


================
Comment at: llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2016-2021
       BaseIsSet = false;
-      Asm->OutStreamer->EmitIntValue(-1, Size);
+      if (DwarfVersion >= 5)
+        Asm->OutStreamer->EmitIntValue(dwarf::DW_RLE_base_address, 1);
+      else
+        Asm->OutStreamer->EmitIntValue(-1, Size);
       Asm->OutStreamer->EmitIntValue(0, Size);
----------------
dblaikie wrote:
> I suspect this section doesn't make sense for DWARFv5 style range lists - there would never be a need to reset the base address to zero, because the forms themselves encode whether they are base address relative or not.
> 
> (in the old style range lists, you'd have to reset the base address to zero because the address pairs didn't describe whether they were absolute or relative - so setting it to zero would make the following address pairs absolute (relative to zero). It'd look more like "<base address> <relative pair> <relative pair> <base address 0> <abs pair> <abs pair>" in the new form it's "base address, relative pair, absolute pair, relative pair, etc" - absolute and relative pairs can be interleaved and each is self-descriptive about its absolute or relativeness)
> 
> Maybe there are some missing test cases too? Though they should be/probably can be covered by the original testing for UseDwarfRangesBaseAddressSpecifier - but so you might be able to reuse the test input for that ( test/DebugInfo/X86/range_reloc.ll ), but use DWARFv5 instead of UseDwarfRangesBaseAddressSpecfier.
> I suspect this section doesn't make sense for DWARFv5 style range lists - there would never be a need to reset the base address to zero, because the forms themselves encode whether they are base address relative or not.

While I don't dispute any of this, is it okay if we defer this work until after location lists are in?  We really want to have a syntactically conforming DWARF 5 before LLVM 7.0 branches, which is just a couple of weeks away.  I think what Wolfgang has done meets that criterion (conforming) even if it isn't taking best advantage of the v5 possibilities.




Repository:
  rL LLVM

https://reviews.llvm.org/D49214