[PATCH] D68620: DebugInfo: Use base address selection entries for debug_loc

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D68620#2290273 <https://reviews.llvm.org/D68620#2290273>, @probinson wrote:

> TL;DR:  It's all good.
>
> As I worked through the calculations again myself, I realized I had forgotten that both the start and end address in a v4 entry were relocated.  (The spec says neither of them are; they are supposed to be relative to the CU base address.  But nobody actually does it that way.)

Oh, they are relative to the CU base address, if there is one - but very few C++ CUs have a relocated base address - because they have code in multiple sections, they use DW_AT_ranges. If you make a simple CU with one function, then the CU gets a traditional low/high_pc - and, say, DW_AT_ranges on a scope inside that one function will be relative to the CU's base address (low_pc) and no relocations would be used (& even with base address selection entries in use - we won't emit a base address selection entry)

eg:

  $ cat loc.cpp
  void f1();
  void f2() {
    int i = 7;
    f1();
    i = 3;
    f1();
  }
  void f3() {
  }
  $ clang++-tot loc.cpp -gdwarf-5 -c -O3 && llvm-dwarfdump-tot -v loc.o -debug-loclists
  loc.o:  file format elf64-x86-64
  
  .debug_loclists contents:
  0x00000000: locations list header: length = 0x0000001b, format = DWARF32, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000001
  offsets: [
  0x00000004 => 0x00000010
  ]
  0x00000010: 
              DW_LLE_offset_pair     (0x0000000000000001, 0x0000000000000006): DW_OP_consts +7, DW_OP_stack_value
              DW_LLE_offset_pair     (0x0000000000000006, 0x000000000000000c): DW_OP_consts +3, DW_OP_stack_value
              DW_LLE_end_of_list     ()

Compared to using function-sections, that'll put f2 and f3 in separate .text sections, forcing the use of DW_AT_ranges at the CU and then LLVM produces a constant zero value DW_AT_low_pc to be clear what the "base address" is (which means basically no base address - everything has to use absolute addressing/explicit base addresses in the range/loc lists):

  $ clang++-tot -ffunction-sections loc.cpp -gdwarf-5 -c -O3 && llvm-dwarfdump-tot -v loc.o -debug-loclists
  loc.o:  file format elf64-x86-64
  
  .debug_loclists contents:
  0x00000000: locations list header: length = 0x0000001d, format = DWARF32, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000001
  offsets: [
  0x00000004 => 0x00000010
  ]
  0x00000010: 
              DW_LLE_base_addressx   (0x0000000000000000)
              DW_LLE_offset_pair     (0x0000000000000001, 0x0000000000000006): DW_OP_consts +7, DW_OP_stack_value
              DW_LLE_offset_pair     (0x0000000000000006, 0x000000000000000c): DW_OP_consts +3, DW_OP_stack_value
              DW_LLE_end_of_list     ()



> So in v4, using the base-address entry is a slight size win for object files, and reduces the total number of relocations.  It has a cost in loadfile .debug_loc size, which is what people were noticing above.
>
> And in v5, the combo of base_addressx/offset_pair is a win over startx_length because the former can reuse the .debug_addr entry for the function entry point.  It shows up as in increase in .debug_loclists but there's a compensating decrease in .debug_addr as long as we actually do reuse a .debug_addr entry.  Our debugger folks will whine about the additional indirection, but that's nothing new; v5 just has a lot more of that.
>
> Orlando's data suggests that the overall build time difference is minimal.  We have no data about debugger load times, but I'd hope that location lists wouldn't be on the critical path there.
>
> My conclusion is: We have a better understanding of where the size difference is coming from; naively it doesn't cause turnaround-time problems.  If we get complaints from licensees, we can revisit this, but I haven't been noticing size complaints in the last couple of years.

Awesome awesome - really appreciate you talking through all this!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68620/new/

https://reviews.llvm.org/D68620